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.

  • Do I get it right : you want to patch the project so that you personal choice of cflags does not give a warning any longer? Commented Aug 30, 2020 at 23:54
  • 1
    Start by writing a bug report wherever you think is most appropriate. The managers of that place will tell you if you should report it somewhere else. If they agree with the bug, then you can submit a patch/pull request. Commented Aug 31, 2020 at 5:22
  • 1
    Note also that the project isn't required to accept any particular bug report. If I alias gcc to /bin/true my builds will fail. If I then log bug reports asking for build mechanisms to support renaming the gcc binary, I may find at least some get closed NOTABUG or WONTFIX, and that decision rests entirely with the project.
    – MadHatter
    Commented Aug 31, 2020 at 6:41
  • @planetmaker: Not a warning, it's a compilation error. Commented Aug 31, 2020 at 7:53
  • 2
    Same applies. You can ask anyone in the chain to accept that this is a bug, but you can't force any of them to agree that it is a bug, or to accept your fix, or to fix it at all. In short: you have no right or power to force someone else to accept your help. You can offer it, and it sounds like you have already engaged with Gentoo to do so; if they don't want it, that's pretty much where it ends.
    – MadHatter
    Commented Aug 31, 2020 at 8:04

2 Answers 2


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.

  • Nice breakdown of options on how to proceed Commented Sep 5, 2020 at 9:45
  • Thanks for giving advice on procedures and flow. The bug is not reproducible on a clean installation, but Gentoo has promised a customizable build system. I think according to your advice It might be better to propose a patch to Gentoo's repository as an "enhancement". This way it's more straightforward to discuss. Commented Sep 5, 2020 at 15:07
  • @AlirezaMohamadi Well sure, you can certainly give that a try. But do keep in mind that when Gentoo offers a customizable build system, it just means that you have the ability to customize your compiler options and apply custom patches and so on. It does not mean that those customizations are supposed to work, and it especially does not mean that the Gentoo devs owe you any help in making them work. In general, when you customize your system, the responsibility for making things work falls on you.
    – David Z
    Commented Sep 5, 2020 at 22:53

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.