PATCH: PR ld/12761: .gnu.warning.* doesn't work when building shared library
Tue May 17 14:36:00 GMT 2011
On Tue, May 17, 2011 at 7:30 AM, Ian Lance Taylor <firstname.lastname@example.org> wrote:
> "H.J. Lu" <email@example.com> writes:
>> On Mon, May 16, 2011 at 11:03 PM, Ian Lance Taylor <firstname.lastname@example.org> wrote:
>>> "H.J. Lu" <email@example.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.
More information about the Binutils