I'm raising this issue as the aftermath of two hard-to-debug issues I've encountered in packages, which were related to this flag[1][2]. This flag is used by both CMake and Meson in release mode, and is used by a fair number of programs, to change the behavior of the program based on the build mode. Gentoo is currently stripping this flag as part of stripping out all the build system's default flags. This is annoying, as many programs expect this flag to be set whenever providing end-user builds, and as shown by the encountered issues, can be the source of runtime bugs and misbehavior. Searching in the portage tree for "-DNDEBUG" gives 241 results, over a total of 60 packages. Some of these hits explicitly mention performance or other issues whenever the flag isn't set. After speaking with sam on IRC, he suggested he's considering enabling the flag globally. This is relatively more risky than enabling it in build systems that already expect the flag, so just enabling it in cmake/meson is also an option. [1]: https://bugs.gentoo.org/754012 [2]: https://bugs.gentoo.org/866055
Here's another related bug regarding clang, which broke a tool depending on -DNDEBUG behavior: https://bugs.gentoo.org/614844 Sam helped me dig into the git history regarding this flag, and dug up the commit where it was removed in 2020[1]. This commit mentions that assert() is being disabled whenever this flag is set, which might be a security concern (allowing subtle programming errors to go unnoticed). This happens in glibc's /usr/include/assert.h. [1]: https://github.com/gentoo/gentoo/commit/95577dd5076a8e9864e82879fd3af97cf63fcfe9
I am against making this change globally. Skipping asserts seems like a bad idea to me. It may result in strange bugs that go unnoticed and cause weird behavior at runtime.
I agree on the basis that skipping asserts is generally bad, but upstreams test and release their code with the flag *set*, at least when it comes to cmake and meson's release modes. Gentoo packages are actively differing from upstream behavior by forcing this flag off, effectively shipping an untested configuration (-O2 -UNDEBUG + system-wide install). This results in strange bugs that go unnoticed and cause weird behavior at runtime. If there was a middle-of-the-road solution to keep asserts and also keep -DNDEBUG, then that could be considered also, but as it stands I would prefer not diverging from upstream behavior over keeping asserts.
(In reply to Esteve Varela Colominas from comment #3) > Gentoo packages are actively differing from upstream behavior by forcing > this flag off, effectively shipping an untested configuration (-O2 -UNDEBUG > + system-wide install). This results in strange bugs that go unnoticed and > cause weird behavior at runtime. Gentoo doesn't "force" it off. We simply don't pass any option (-DNDEBUG or -UNDEBUG) by default. For meson, we pass "--buildtype plain" to start with a clean slate and allow the user to choose what options they wish to pass to the compiler. I would expect other build systems to work similarly.
(In reply to Esteve Varela Colominas from comment #3) > I agree on the basis that skipping asserts is generally bad, but upstreams > test and release their code with the flag *set*, at least when it comes to > cmake and meson's release modes. It seems to me that NDEBUG should be reserved for controlling asserts, and nothing else. It's been used for that purpose in glibc for a long time. I would encourage upstream developers not to abuse it for other purposes.
(In reply to Mike Gilbert from comment #4) > Gentoo doesn't "force" it off. We simply don't pass any option You're right, this is what I meant. Gentoo wipes default compiler flags, some of which are preprocessor definitions, which upstream developers expect to be present in end-user builds of a program. Maybe this question would be better titled "respect upstream default preprocessor definitions (unless manually overridden, or overridden by the ebuild, of course)", but this happens to be the only one. (In reply to Mike Gilbert from comment #5) > I would encourage upstream developers not to abuse it for other purposes. It unfortunately has a very generic name that doesn't convey the implication and has been used to detect whether the program is being built in "debug" mode (whatever the program decides that means) for decades, to the point of being suggested (without mentioning assert) in some of the guides I used when learning C, over 8 years ago. This train has looooooong passed.
> this happens to be the only one I should clarify, this is the only one I've noticed. I haven't verified Meson's default flags in release mode.
I don't think there's going to be some magic global solution to this problem. It will probably fall on ebuild maintainers to ensure that any necessary upstream defaults are respected.
Yeah, I agree, not a single default configuration will work for every project out there. I just think that respecting upstream defaults by default would avoid most instances of this issue, since a flag unexpectedly being removed by an eclass is very easy to miss.
(In reply to Mike Gilbert from comment #8) > I don't think there's going to be some magic global solution to this > problem. It will probably fall on ebuild maintainers to ensure that any > necessary upstream defaults are respected. Exactly, so this should go to specific packages.
I think CMake at minimum needs handling here and I'm still not against it globally eventually.
Again, the problem is that we're clearing build system defaults that some upstreams are (knowingly or unknowlingly) relying upon.
