http://sourceware.org/bugzilla/show_bug.cgi?id=15478
--- Comment #3 from Cary Coutant <ccoutant at google dot com> 2013-05-17 04:50:56 UTC --- > Yes that mode of operation does work but is unfortunately not an option for us > as we would like to combine libmylib.so with a different API-compatible > libmyplugin.so in each of a whole range of myapp executables. To resolve the > symbol in the libmylib.so build would mean building a number of libmylib.so > (one for each libmyplugin.so) and this would make our build take much more > time, as well as inflating the size of our releases. > > It seems that it should be fairly easy for gold to broaden its 'as-needed' > criteria by scanning for unresolved symbols in the .so files (as well as in > the > .o files) being linked. That would seem to make the behaviour compatible with > the old behaviour of the old linker. 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. > If that's not possible then -no-as-needed should be the default I think. It is the default in gold, but GCC recently started passing --as-needed to the linker by default. -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
