[Bug gold/15478] -no-as-needed required to avoid runtime symbol lookup error

[sparkprime at gmail dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=15478

--- Comment #6 from Dave Cunningham <sparkprime at gmail dot com> 2013-05-17 
19:45:56 UTC ---
> In this specific case, yes, no searching is necessary, but in the
> general case, if we're going to try to resolve undefined symbols in
> shared libraries, we need to process the dependencies of those shared
> libraries, which means trying to find them via the embedded rpaths in
> those libraries.

So it seems in the general case, if you have an undefined symbol in a library,
you cannot be sure from where it is intended to be satisfied.

If it is a symbol that is *not* provided by any other library on the linker
commandline, then it's a reasonable assumption that it should be satisfied
externally (i.e. via dynamic linking).  So then it can safely be ignored.

But if that symbol is present in a file on the linker commandline then that
seems like a pretty strong hint that it is intended to be satisfied using that
specific arrangement.

The problem I have with this is that -as-needed is second-guessing the build
system.  If a library is not needed, the build system can choose not to add it
to the linker commandline.  So this really ought to be a transparent
optimisation, which means it should use the most precise heuristics available
and err on the side of caution where merited.  In this case, erring on the side
of caution means deciding that a library is indeed needed.  This seems to be
the policy of the old implementation.

If it's not intended to be a transparent optimisation, then it is clearly only
applicable in specific cases and should not therefore be the default behaviour
of gcc.  But gcc may be assuming that -as-needed behaves like the old ld and is
therefore safe to turn on by default.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.