tech-toolchain archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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

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):

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 and exp2 in, both referenced from

So I want the client binary to have:

  NEEDED        Shared library: []

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

  NEEDED        Shared library: []
  NEEDED        Shared library: []
  NEEDED        Shared library: []

(which is old binutils default) or:

  NEEDED        Shared library: []
  NEEDED        Shared library: []

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 With new binutils default, things will fail. With old
default, they will work as long as I still provide and

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.


Home | Main Index | Thread Index | Old Index