--as-needed by default
Alexandre Oliva
aoliva@redhat.com
Tue Mar 8 23:22:00 GMT 2005
On Mar 8, 2005, Zack Weinberg <zack@codesourcery.com> wrote:
> In the sense that, if you write -lfoo on the link command line, and
> libfoo.a is a static library which satisfies no undefined symbols from
> the link up to this point (assume -( -) are not in use) then no
> objects from libfoo.a will be included in the final linked image
> Autoconf's AC_CHECK_LIB macro assumes this semantic.
AC_CHECK_LIB isn't a test for whether a library is needed to satisfy a
symbol. It's a test for whether the library exists and can be linked
with and, while at that, making sure a symbol is defined when the
library is linked in (even if it would also be defined without it).
So changing the linker in a non-straightforward way to work around a
bug in gazillions of programs doesn't sound like a good plan to me.
Also, arguing that it would make the link-time semantics of shared
libs closer to that of static libs isn't necessarily a strong
argument. Consider the argument to stop opening DT_NEEDED libraries
of dynamic libraries listed in the command line, so that people have
to specify dependencies explicitly, just like they have to do with
static libs.
>> Consider a library libfoo that is linked with libbar not because it
>> uses symbols from libbar, but because libbar used to be part of its
>> API before the code was split into a separate library.
>> Dropping libbar from libfoo's DT_NEEDED would break programs linked
>> with libfoo, and even force libfoo to change its SONAME.
> I doubt this case has ever arisen in practice, because it is
> impossible to do a similar backward compatibility hack with static
> libraries, and most people still support static libraries. Also,
> wouldn't a GROUP() script be a better choice (as e.g. used in glibc)?
For link-time, yes. But the issue at hand is the construction of
libfoo, that would, after your proposed change, require a
--no-as-needed to make sure the dep on the libbar dynamic lib is not
dropped.
--
Alexandre Oliva http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org}
More information about the Binutils
mailing list