This is a generalization of bug 12017. Compilers typically allow the user to suppress specific warnings, either globally or locally at specific places in the code. Now, the linker apparently emits a warning when a symbol is used whose library entry(/ies) indicate such a warning needs to be emitted. It should have an option to suppress such warnings, in at least the following resolutions IMHO: 1. Globally 2. By (library, symbol name) pair 3. By library (e.g. glibc warnings) 4. By call site Let's ignore (4.) for now because this is more complex and would require compiler support for users to make work and focus on (1.)through (3.) . IIANM, neither is currently possible with ld right now. Now, (1.) should be really easy to implement; and (2.) and (3.) should not be difficult to implement, and in a away such that the cost is minimal (e.g. have a flag for whether _any_ specific suppressions are used, so when none are used it's an extra flag check when having to emit a warning - a tolerable cost.) If this were implemented, it would allow for an easy resolution of 12017.
Hi Eyal, 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. The warnings are important, and the real way to get rid of them is to fix the code that is triggering them. Now I appreciate that this is not always possible. 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. 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). Cheers Nick
(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?
(In reply to Nick Clifton from comment #1) > 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. Because addressing this in the linker requires the solution to be put in one place and makes it easily accessible (via command-line switch) to all who want to use it. Any bugs introduced thus need only be fixed in one place. The workarounds require each user to develop his own custom solution to the same problem, increasing the complexity of development. And every one of these ad hoc solutions would have to be maintained and debugged separately. It's a basic application of the concept of modular design. Localize a recurringly needed solution in one place rather than requiring everyone to invent it independently.