The code calls an essential function within an assert() macro. When NDEBUG is defined, all assert-macros become no-ops and thus the function will not be called, resulting in a crash when the search function is invoked. Reproducible: Always Steps to Reproduce: 1.Start the search function while viewing a file 2.Enter some ASCII string which will not be found Actual Results: Segmentation violation. Expected Results: Should not crash.
Created attachment 140657 [details, diff] Patch fixing the NDEBUG problem Applying the patch makes the ebuild compile fine with or without -DNDEBUG defined in $CFLAGS.
Erm, we don't support any such stuff in C[XX]FLAGS... Did you submit this upstream? @dragonheart - btw, could the ebuild use eqmake4 from the eclass instead?
(In reply to comment #2) > Erm, we don't support any such stuff in C[XX]FLAGS... Sorry, I didn't know that. Anyway, I have been able to rebuild my entire system with -DNDEBUG long ago with no problems so far whatsoever - except for clanlib which had a similar NDEBUG-related problem like lfhex. I then filed a bug report and patch for clanlib; the patch was added and clanlib compiles fine with NDEBUG from then on. So lfhex would be the only package around so far (I am aware of) which would not be capable of creating a "release version": Note that the ANSI-C Standard explicitly states that the preprocessor symbol NDEBUG *should* be defined for compiling non-debug versions of executables. This will make all assert() macros into no-ops, turning off debug runtime validation checks and thus making the code run faster. Which means defining NDEBUG is not a strange idea of my behalf, nor it is a Gentoo-, Linux- or even GNU-specific issue - defining NDEBUG for release versions is recommended by the very ANSI-C standard itself! Which also means that any correct standard-compliant ANSI-C program *must* work out of the box with NDEBUG defined - otherwise that can be considered a (minor) bug. But besides any philosophical concerns - defining NDEBUG makes many applications run a lot faster, because it disables all assert() runtime validation checks, which, as defined by the standard, have to be purely optional. A correct standard-compliant ANSI C program must behave exactly the same (except for running speed) with or without NDEBUG defined. And as Gentoo is all about choices - why should one not be allowed to also choose ultimate speed (and thus add -DNDEBUG to $C[XX]FLAGS)? The Gentoo penguin is the fastest swimmer among penguins, and it swims even faster with NDEBUG defined! :-) Did you submit this > upstream? I have posted the patch and a bug report to the forum on the upstream developer's site. But frankly, I have doubts the developer will ever look there - the forum looks rather abandoned to me. My impression (which might be wrong) is that upstream doesn't care about the project any more, and thus might never fix the bug. So please consider adding the patch anyway - if upstream really ever fixes the bug, it's easy to just drop it.
added - thanks Jakub and Guenther
