Re: PATCH: PR ld/12761: .gnu.warning.* doesn't work when building shared library

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

On Tue, May 17, 2011 at 7:30 AM, Ian Lance Taylor <iant@google.com> wrote:
> "H.J. Lu" <hjl.tools@gmail.com> writes:
>
>> On Mon, May 16, 2011 at 11:03 PM, Ian Lance Taylor <iant@google.com> wrote:
>>> "H.J. Lu" <hongjiu.lu@intel.com> writes:
>>>
>>>> We should issure a gnu warning when building shared library. ?This patch
>>>> implements it. ?OK for trunk?
>>>
>>> No, this is not how warning symbols are supposed to work. ?We only want
>>> to issue the warning for a warning symbol if there is some reference to
>>> the symbol in the main program. ?If we issue the warnings for a shared
>>> library, then we will wind up issuing the warnings even if the program
>>> does not ever refer to the symbol. ?That is undesirable and will almost
>>> certainly break some uses of warning symbols.
>>
>> We aren't consistent:
>>
>> 1. Gold always issues a warning when building a shared library.
>> 2. Ld sometimes issues a warning when building a shared library:
>
> Hmmm, that's interesting. ?Sounds like an oversight on my part, but
> perhaps it doesn't matter.
>
>
>>> I think it would be reasonable to issue a warning when building a shared
>>> library for a reference to a symbol defined in some other shared
>>> library, but it is necessary to not give a warning for references to
>>> symbols defined in the library being created.
>>>
>>
>> What is the difference between defined inside vs outside of DSO?
>> They both reference a function with a warning.
>
> The difference is that the author of a shared library can call a
> function with a warning safely from another externally visible function
> which does not require a warning.
>

How does linker know warning is from the author of a shared library.
A shared library may contain many 3rd party objects.

-- 
H.J.