Re: "Fixing" new ld(1) DT_NEEDED handling

[Martin Husemann <martin%duskware.de@localhost>]

On Sat, Oct 12, 2013 at 05:32:57PM +0200, Rhialto wrote:
> The original change in behaviour is explained here (from the top of
> that thread):         http://fedoraproject.org/wiki/UnderstandingDSOLinkChange

I see their reasoning, but the change has downsides as well.
However, the worst thing, IMHO: with neither the option on or off we get the
behaviour we realy want in the indirect reference case.

Let's assume I provide a set of shared libraries exporting a documented
API consisting of exp1 and exp2 functions, and I document clients need to
-lmymainlib. Internally I implement exp1 in libmysublib1.so and exp2 in
libmysublib2.so, both referenced from libmymain.so.

So I want the client binary to have:

  NEEDED        Shared library: [libmymain.so]

but the only options (AFAICT) with gnu ld are either

  NEEDED        Shared library: [libmymain.so]
  NEEDED        Shared library: [libmysublib1.so]
  NEEDED        Shared library: [libmysublib2.so]

(which is old binutils default) or:

  NEEDED        Shared library: [libmysublib1.so]
  NEEDED        Shared library: [libmysublib2.so]

which is new binutils default.

Now imagine I (binary) update my shared library (but not the client program)
and internally have rearanged things, so exp2 is now implemented in
libmysublib3.so. With new binutils default, things will fail. With old
default, they will work as long as I still provide libmysublib1.so and
libmysublib2.so.

But we realy want to only generate the NEEDED entries we ask for, and not
the linker to outsmart the makefile. This seems currently impossible with
gnu ld.

Martin