This is the mail archive of the
mailing list for the binutils project.
Re: --as-needed change wrt undefined weak symbols
On Mon, Jan 14, 2013 at 9:23 PM, Alan Modra <firstname.lastname@example.org> 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 <email@example.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.