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. _______________________________________________ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
