[Bug ld/26701] Ability to suppress warnings due to tags in a library

[eyalroz at technion dot ac.il]

https://sourceware.org/bugzilla/show_bug.cgi?id=26701

--- Comment #2 from Eyal Rozenberg <eyalroz at technion dot ac.il> ---
(In reply to Nick Clifton from comment #1)
>   Yes, the linker could suppress these warnings.  But the important point
>   is that it is not at all clear that the linker should suppress them.

Oh, but of course the linker shouldn't suppress them _by default_. We're only
talking about an optional suppression. 

>   The warnings are important, and the real way to get rid of them is to
>   fix the code that is triggering them.

Warnings may be important. But - sometimes, they are acceptable, otherwise
they'd be errors. It's not always the case that "real" way to avoid warnings is
to avoid code with warning-trigger.

Examples:

* You may not have access to the code that's triggering them, which is buried
deep in some library (whose functionality you require).
* The problematic code may be mandated by certain policy in your organization
* The code is only problematic under certain circumstances, but you actually
guarantee that they never occur (e.g. in a wrapper function).

>   Now I appreciate that this is not always possible.

It's also sometimes not even useful or desirable.

>  But as pointed out
>   in PR 12017 there are several ways to work around the problem without
>   modifying the linker.  My stance is: why introduce new code, and 
>   potentially new bugs, to the linker when there are other ways of solving
>   the problem.

I respectfully disagree, for several reasons, the most important one being: It
is a near-universal universal custom to allow silent non-erroneous operation of
command-line-focused applications. More specifically - if a compiler lets you
suppress warnings - so should the linker.

Let me consider your suggested solutions:

> *) You could post-process gcc's output and strip out the warning message.

This is possible, but in any non-trivial setup - e.g. a build system like CMake
or autotools, or a linker launched by another process and not by gcc or by me
from the shell - it is somewhat complicated. Also, introduction of a wrapper
script will almost certainly be required in many places, so it's actually quite
a bit of work, repeatedly.

Also - why should gcc or clang users not have to write wrapper scripts to
suppress the warnings they get?

>  *) You could remove the offending section (.gnu.warning) from the C library 
> (in the tmpman.o archive element)

This is actually a pretty bad idea. We don't want to have all sort of modified
versions of the C library - nor have build systems start looking for these
custom versions. And if we replaced the default one with a modified version -
well, actually, no sysadmin in their right mind would let me do that, and if I
did, I bet there would be all sorts of subtle breakage in binary packages.

>  *) You could use a custom linker script that discards the particular 
> .gnu.warning section.

This requires a level of knowledge beyond that of most linker users, who don't
even know what linker scripts are.


>   So, if you do want to get a change like this in, I think that you are
>   going to need to drum up some support from the community.  If enough
>   people agree with you, then I will make the necessary changes.  One
>   important point however is that you ought to make sure that the LLVM
>   community agrees with the idea too, and that they are willing to put
>   it into their linker (LLD).

Well, I'm not really in the "build toolchain community", to be honest. But I
can certainly file a similar bug against LLD.

Remember, though, that this change requires little effort and does not change
default behavior. 

The potential "normative drawback" is that introducing it will make it easier
for people to be careless and just ignore all warnings straight away without
ever considering them. If that is your main concern, then why not implement
just (2.) and (3.), or even just (2.), to make people be specific, and thus
make them be conscious of every suppression decision they make?

-- 
You are receiving this mail because:
You are on the CC list for the bug.