http://sourceware.org/bugzilla/show_bug.cgi?id=15478
--- Comment #5 from Cary Coutant <ccoutant at google dot com> 2013-05-17 18:48:34 UTC --- >> I think this is a behavior of the Gnu linker that gold is better off >> not copying. The linker ends up having to replicate the path searching >> done at runtime by the dynamic loader, and that works only when the >> libraries are in their installed locations. Making that work at >> development time leads to all kinds of unexpected behavior. > > I don't see any need for additional searching. The linker already has to > search for the library through the paths specified by -L, and it needs to read > the library to ensure that unresolved symbols in the .o files can be bound in > the libraries. So all the information is already available. 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. -cary -- 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
