Bug 404411 – sys-devel/gcc USE=-gcj CFLAGS="-DN?DEBUG"

• Product: Gentoo Linux
• Status: RESOLVED INVALID

[Description Guenther Brunthaler 2012-02-18 16:30:53 UTC]

-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.

[Comment 1 Guenther Brunthaler 2012-02-18 16:33:15 UTC]

Created attachment 302395 [details]
Output of emerge --info

[Comment 2 Jeroen Roovers (RETIRED) 2012-02-18 18:31:44 UTC]

(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.

[Comment 3 Guenther Brunthaler 2012-02-18 19:18:19 UTC]

> > -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.

[Comment 4 Ryan Hill (RETIRED) 2012-02-18 23:03:37 UTC]

Use CPPFLAGS for preprocessor definitions.

[Comment 5 Guenther Brunthaler 2012-02-18 23:39:23 UTC]

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.

[Comment 6 Ryan Hill (RETIRED) 2012-02-19 00:29:25 UTC]

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.

[Comment 7 Guenther Brunthaler 2012-02-19 01:51:56 UTC]

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.