Re: [PATCH] Fix gcc.dg/attr-weak-hidden-1{,a}.c

[Richard Guenther <richard dot guenther at gmail dot com>]

On Mon, Feb 21, 2011 at 1:10 PM, Richard Sandiford
<rdsandiford@googlemail.com> wrote:
> Richard Guenther <richard.guenther@gmail.com> writes:
>>>> I am not even sure that the linking result is well-defined just by
>>>> the linking order on the linker command-line. ?Does ELF symbol
>>>> resolution as specced even have such?
>>>
>>> I suppose link-line order isn't really an ELF-level thing. ?It is
>>> guaranteed by GNU ld, and by other linkers I've used (admittedly a
>>> relatively small set). ?It's not that unusual for the weakness of
>>> a symbol to be defined in a header file -- that's how you typically
>>> get undefined weak symbols.
>>
>> Sure, but that's unrelated to this case where you have two semantically
>> different weak definitions, not undefined weak symbols.
>
> What I said was related. ?What I meant was: it's not uncommon for
> weakness to be defined in the header file. ?It's also not uncommon for
> .c files that define a function to include a .h that declares the
> function. ?If you combine those two approaches for a function with two
> possible definitions _within the same package_ (as was the case with the
> original bug), then both definitions will be weak definitions, as here.

Right, but in 99% (or even more) of all cases they are semantically equivalent
and thus linking order doesn't matter.

Richard.