This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Fix DT_NEEDED search with --as-needed libraries (PR ld/2721)

On Fri, Jun 02, 2006 at 02:43:44PM +0930, Alan Modra wrote:
> On Thu, Jun 01, 2006 at 05:09:07PM +0200, Jakub Jelinek wrote:
> > If some --as-needed library mentioned on the command line isn't directly
> > needed by executable being linked, but it is mentioned in DT_NEEDED of some
> > needed library, then without this patch ld will disregard the library
> > mentioned on the command line and look for a different one (e.g. in system
> > paths).
> According to the current specification of --as-needed, isn't that
> exactly what ld should do?  --as-needed is supposed to cause ld to only
> link a lib if it satisfies some reference from a regular object
> (ie. non-dynamic) at that point in the link process.  This patch makes
> --as-needed have another meaning entirely.
> I'm willing to consider a behaviour change for --as-needed, eg. that
> references from other dynamic libs cause a lib to be linked, but this
> particular change seems a little odd.  Why should a library that you
> decide isn't needed be considered again, unless it is also found by the
> normal search mechanism?

Because without it --as-needed isn't really usable with libtool,
unless libtool is changed to pass -Wl,--rpath-link with every single library
it adds (and even in that case it might do unexpected things if there are
multiple libraries in the same directory).
The testcase in the PR is a simplified version of
which is I think quite commonly used scenario.  A project that builds
2 or more shared libraries in the build process, where the second of these
depends on the first one, and then build a binary that depends on the second
of the shared library (but doesn't have direct dependencies on the first).
The first library is actually needed by the program, as it is a dependency
of the second, but as it is not a direct dependency, it is not needed
in DT_NEEDED of the program.
The --as-needed documentation doesn't talk about linking/not linking some
library, it solely talks about DT_NEEDED:
     This option affects ELF DT_NEEDED tags for dynamic libraries
     mentioned on the command line after the `--as-needed' option.
     Normally, the linker will add a DT_NEEDED tag for each dynamic
     library mentioned on the command line, regardless of whether the
     library is actually needed.  `--as-needed' causes DT_NEEDED tags
     to only be emitted for libraries that satisfy some symbol
     reference from regular objects which is undefined at the point
     that the library was linked.  `--no-as-needed' restores the
     default behaviour.
With the patch I posted, the first library won't be in binary's DT_NEEDED,
which matches the documentation, but there is no word about --as-needed
affecting anything else, particularly what libraries are searched when
trying to satisfy undefined references in shared libraries mentioned

The second testcase in the PR is a regression from 2.16.90.x.y btw.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]