Open Source Asked by Alireza Mohamadi on January 30, 2021
My distro (Gentoo) has added a patch to GCC that enables an internal macro.
I already have enabled that macro in my CFLAGS for a while. I asked them on their IRC about this issue, that now GCC warns about overridden macros, and in some cases when -Werror flag (Docs) is enabled as well, either compilation or configuration of some specific packages fail.
First, they told me that their policy is to disable -Werror in all packages (ebuilds), which seemed not to be the case here. Then they began blaming me for adding a macro to CFLAGS (while the package manager, portage, supports adding more flags).
One such case is PulseAudio, in their configuration script in a specific part, they force -Werror (this seems reasonable to me because a developer wants to know about possible flaws).
Now, what should I do? Should I open a bug report in Gentoo’s own issue tracker, or in the upstream’s (PulseAudio)? (I’ve already written the patch for a possible pull request).
P.S. That macro is -D_FORTIFY_SOURCE=1.
Generally speaking, you propose the fix to whichever group created the code that caused the issue. So in your case, if the possible bug you're trying to fix is caused by some code in the upstream project (e.g. PulseAudio), you should file a bug report and propose your fix in the upstream project. If the bug is caused by code in Gentoo, such as a patch applied by an ebuild, then you should file your report and propose the fix in the Gentoo bug tracker.
In the former case, if the bug is caused by upstream code, generally it should be possible to confirm it by reproducing the bug without any Gentoo-specific infrastructure. Download and compile the upstream project's source code manually, following the instructions they give, and tweak compiler options or whatever you need to do to get the bug to occur. Ideally, you would even do it on a non-Gentoo system or two. This has two benefits: first, it proves that the bug has nothing to do with any customizations applied by Gentoo or anyone else, and second, it lets you work out a clear procedure for reproducing the bug, which will be tremendously valuable to the upstream project's developers when they are evaluating your bug report.
If you're quite confident that the bug does not exist in the upstream code, but it was introduced by some Gentoo-specific customization, then you can propose to the Gentoo people that they change that customization. Again, it's tremendously valuable if you can make it happen on a clean Gentoo system configured in the standard way. That proves that the bug has nothing to do with any customizations you may have applied, and it also allows the developers to reproduce it.
Of course, you may run into a situation where it's not possible to reproduce the bug on a clean Gentoo system, and in that case you have to consider the option that it's your specific environment that causes the bug. In that case, you're on your own. The "group" that created the code that caused the issue is you, and therefore the only person you can really report the issue to is yourself.
Answered by David Z on January 30, 2021
A bug report with the upstream maintainers is not likely to be accepted. It is not a bug in their build scripts that you force-define a macro that a new version of the compiler also defines, especially as it is a macro with a leading underscore, which are reserved for use by implementers of C and C++.
If it is a Gentoo policy to remove all uses of the -Werror flag, then a bug report that points one out that has been missed might be accepted, but there could also be reasons why this particular instance is left in.
In the end, the most reliable course of action is to remove this macro from your local, custom, CFLAGS definition.
Answered by Bart van Ingen Schenau on January 30, 2021
Get help from others!
Recent Questions
Recent Answers
© 2024 TransWikia.com. All rights reserved. Sites we Love: PCI Database, UKBizDB, Menu Kuliner, Sharing RPP