--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