Re: --as-needed change wrt undefined weak symbols

["H.J. Lu" <hjl dot tools at gmail dot com>]

On Mon, Jan 14, 2013 at 9:23 PM, Alan Modra <amodra@gmail.com> wrote:
> On Mon, Jan 14, 2013 at 07:30:24PM -0800, H.J. Lu wrote:
>> On Mon, Jan 14, 2013 at 6:23 PM, Alan Modra <amodra@gmail.com> wrote:
>> > On Mon, Jan 14, 2013 at 07:30:54AM -0800, H.J. Lu wrote:
>> >> Given then the behavior of pr14862 is changed,
>> >> I don't think it is a good idea.
>> >
>> > You added a testcase in November last year that (possibly
>> > accidentally) depends on the current --as-needed behaviour for weak
>> > references.  Now you claim that testcase as a reason to not change
>> > --as-needed.  How is that a reasonable objection?
>> >
>>
>> It shows that this patch will change the behavior of some
>> programs.  Adding DT_NEEDED is one thing. Change
>> program behavior is another. I don't think we should do it
>> by default.
>
> Of course this patch potentially changes program behaviour.  I'd
> argue that people using undefined weak symbols are prepared for and
> indeed expect such changes in behaviour.  The PR12549 reporter and

The input file works with undefined weak symbol. The issue
is the expected program behavior for a given command line.
If libfoo.so provides a definition for weak undefined symbol,
it is used as of today.

> another commenter quite reasonably call ld --as-needed buggy in that

Sure, add a new option.  But we shouldn't change the existing option.

> we get a library added to DT_NEEDED only to satify an undefined weak
> symbol.  If the same program were linked against archive libraries
> supplying the same functionality you'd find the undefined weak symbols
> would stay undefined.
>

People know linker treats archive and shared object differently.

-- 
H.J.