--as-needed by default

Zack Weinberg zack@codesourcery.com
Tue Mar 8 17:53:00 GMT 2005


Alexandre Oliva <aoliva@redhat.com> writes:

> On Mar  3, 2005, Zack Weinberg <zack@codesourcery.com> wrote:
>
>> I've argued in the past for --as-needed to be the default, because it
>> makes shared library semantics match static library semantics,
>
> In what sense?  I can come up with numerous examples in which it still
> wouldn't match.  In fact, in *most* cases it still wouldn't match.  I
> can't however figure out what particular example would make them
> match.

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, even
if there might have been some other reason for them to be included
(such as C++ global constructors).

Autoconf's AC_CHECK_LIB macro assumes this semantic.  Yes, there is
now AC_SEARCH_LIBS that doesn't, but AC_CHECK_LIB is not deprecated
and is still widely used.  Because AC_CHECK_LIB is used in a
widely-copied recipe for getting at the socket API on Solaris, there
are 238 binaries on my Linux box that have an unnecessary DT_NEEDED
for libnsl.so.1.¹

>> and because it takes a quite contrived application to depend on
>> DT_NEEDEDs for libraries that satisfy no symbols.
>
> Not really.  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)?

zw

¹ On a glibc system, the only thing in libnsl is NIS helper routines,
so the only things that should be linked with libnsl are the NIS
servers and utilities, and a few NSS modules.



More information about the Binutils mailing list