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

H.J. Lu
Tue May 17 14:36:00 GMT 2011

On Tue, May 17, 2011 at 7:30 AM, Ian Lance Taylor <> wrote:
> "H.J. Lu" <> writes:
>> On Mon, May 16, 2011 at 11:03 PM, Ian Lance Taylor <> wrote:
>>> "H.J. Lu" <> 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.


More information about the Binutils mailing list