-DNDEBUG disables assert() code paths, creating faster and smaller executables. gcc compiles fine with -DNODEBUG as long as the "gcj" USE flag is not also used. Reproducible: Always Steps to Reproduce: 1. Try to emerge GCC with the gcj USE flag set and -DNDEBUG in your $CFLAGS. Actual Results: After a while, the build fails for java/lang/.libs/Object.o with the error message "gcj: can't specify '-D' without '--main'" Expected Results: Should compile fine. The command which triggered the problem when it was attempted to be executed was: $ cd /var/tmp/portage/sys-devel/gcc-4.5.3-r1/work/build/x86_64-pc-linux-gnu/libjava $ /bin/sh ./libtool --tag=GCJ --mode=compile /var/tmp/portage/sys-devel/gcc-4.5.3-r1/work/build/./gcc/gcj -B/var/t mp/portage/sys-devel/gcc-4.5.3-r1/work/build/x86_64-pc-linux-gnu/libjava/ -B/var/tmp/portage/sys-devel/gcc-4.5.3-r 1/work/build/./gcc/ -B/usr/x86_64-pc-linux-gnu/bin/ -B/usr/x86_64-pc-linux-gnu/lib/ -isystem /usr/x86_64-pc-linux- gnu/include -isystem /usr/x86_64-pc-linux-gnu/sys-include -fomit-frame-pointer -fclasspath= -fbootclasspath=/va r/tmp/portage/sys-devel/gcc-4.5.3-r1/work/gcc-4.5.3/libjava/classpath/lib --encoding=UTF-8 -Wno-deprecated -fboots trap-classes -march=amdfam10 -Wl,-O1,--hash-style=gnu -DNDEBUG -pipe -O2 -c -o java/lang/Object.lo -fsource-filena me=/var/tmp/portage/sys-devel/gcc-4.5.3-r1/work/gcc-4.5.3/libjava/java/lang/Object.java /var/tmp/portage/sys-devel /gcc-4.5.3-r1/work/gcc-4.5.3/libjava/classpath/lib/java/lang/Object.class /bin/sh ./libtool --tag=GCJ --mode=compile /var/tmp/portage/sys-devel/gcc-4.5.3-r1/work/build/./gcc/gcj -B/var/t mp/portage/sys-devel/gcc-4.5.3-r1/work/build/x86_64-pc-linux-gnu/libjava/ -B/var/tmp/portage/sys-devel/gcc-4.5.3-r 1/work/build/./gcc/ -B/usr/x86_64-pc-linux-gnu/bin/ -B/usr/x86_64-pc-linux-gnu/lib/ -isystem /usr/x86_64-pc-linux- gnu/include -isystem /usr/x86_64-pc-linux-gnu/sys-include -fomit-frame-pointer -fclasspath= -fbootclasspath=/va r/tmp/portage/sys-devel/gcc-4.5.3-r1/work/gcc-4.5.3/libjava/classpath/lib --encoding=UTF-8 -Wno-deprecated -fboots trap-classes -march=amdfam10 -Wl,-O1,--hash-style=gnu -DNDEBUG -pipe -O2 -c -o java/lang/Class.lo -fsource-filena me=/var/tmp/portage/sys-devel/gcc-4.5.3-r1/work/gcc-4.5.3/libjava/java/lang/Class.java /var/tmp/portage/sys-devel/ gcc-4.5.3-r1/work/gcc-4.5.3/libjava/classpath/lib/java/lang/Class.class I could verify this be re-executing this command in a sandbox shell environment, using the temp/environment which was placed there by the failed ebuild. The same error message appeared. When I removed all "-DNBDEBUG" arguments from the same command, it compiled just fine. I suspect, the ./libtool script might mismatch the -D option for the C compiler (from CFLAGS) with a -D option for the java compiler where it seems to have different semantics. As a workaround, I removed -DNDEBUG from my CFLAGS for this ebuild. However, this is a suboptimal solution because omitting -DNDEBUG may lead to inefficient code generation for release versions of executables.
Created attachment 302395 [details] Output of emerge --info
(In reply to comment #0) > -DNDEBUG disables assert() code paths, creating faster and smaller executables. Really? I suggest you remove it permanently because the outcome will never be predictable.
> > -DNDEBUG disables assert() code paths, creating faster and smaller executables. > > Really? Obviously. Removing executable statements from an program can hardly make it slower or larger. > I suggest you remove it permanently because the outcome will never be > predictable. I have done this already as a workaround. However, the fact that a program exposes different behaviour whether or not NDEBUG is defined must be considered to be a bug. I quote from the ANSI/ISO C Standard 9899-1990, section 7.2: > 7.2 Diagnostics <assert.h> > > The header <assert.h> defines the assert macro and refers to another macro, > > NDEBUG > > which is nor defined by <assert.h>. If NDEBUG is defined as a macro name > at the point in the source file where <assert.h> is included. The assert > macro is defined simply as > > #define assert(ignore) ((void)0) The possibility of compiling a C source file with NDEBUG defined is therefore explicitly documented in the Standard. And, BTW, I have 1800+ Ebuilds installed, all but a hand full of which have been compiled with -DNDEBUG and are working fine. The remaining few, gcc with gcj USE flag included, fail when NDEBUG is defined, most of them because they are using side-effects of assert() which is clearly a bug. But in the case of gjc, it's not even that - the -D option is mismatched; the bug also occurs if a different symbol than NDEBUG is defined. See http://forums.gentoo.org/viewtopic-p-6875340.html?sid=d3f66a2ad9ec5d6e16327d5bb1961e39 for an example. This *is* a bug.
Use CPPFLAGS for preprocessor definitions.
CPPFLAGS is not a documented item of $ man 5 make.conf There are only CFLAGS and CXXFLAGS listed. Is this a portage documentation bug? I am using sys-apps/portage-2.1.10.44.
No, since CPPFLAGS isn't something the average user should be setting. Neither should you, but if you want to do it CPPFLAGS is the place.
Confirming: gcc compiles fine with USE=gjc and CPPFLAGS="-DNDEBUG". I likewise detected the undocumented LDFLAGS in the output of "emerge --info", and moved my linker-related flags from CFLAGS there: LDFLAGS="-Wl,-O1 -Wl,--as-needed -Wl,--hash-style=gnu" This also worked fine. Thanks for the instructions! Issue resolved.
