Re: --as-needed by default

[Zack Weinberg <zack at codesourcery dot com>]

Alexandre Oliva <aoliva@redhat.com> writes:

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

You are making a distinction that is not made by the Autoconf manual,
nor is it evident to the vast majority of autoconf users.

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

I don't agree that it is a non-straightforward change, and I would far
rather do that than attempt to fix each of the gazillions of programs
individually.

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

What I was saying is, I don't think anyone has ever attempted, or is
likely ever to attempt, to construct such a libfoo.so, because it
wouldn't help with the corresponding libfoo.a.  People instead bite
the bullet and increment libfoo's soname.  Therefore I do not think
this is a case to be worried about.

zw