Summary: | Enable -DNDEBUG by default | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Esteve Varela Colominas <esteve.varela> |
Component: | Profiles | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
Status: | CONFIRMED --- | ||
Severity: | normal | CC: | sam |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: |
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108022 https://bugs.gentoo.org/show_bug.cgi?id=614844 https://bugs.gentoo.org/show_bug.cgi?id=754012 https://bugs.gentoo.org/show_bug.cgi?id=866055 https://bugs.gentoo.org/show_bug.cgi?id=796662 |
||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Esteve Varela Colominas
2022-12-08 00:52:01 UTC
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. |