build failure on solaris-sparc (original) (raw)

Weijun Wang weijun.wang at oracle.com
Thu Sep 15 01:13:38 UTC 2011

If there is not a bug filed already against java/build we should get one filed.

7090807

-Max

On 09/14/2011 10:45 PM, Kelly O'Hair wrote:

It has recently become apparent that Solaris is moving into the C99 arena, accidentally in some places, and on purpose in others. Many of the Solaris developers are unaware of the C99 features they are using or inflicting on everyone via /usr/include files, mostly because the default 'cc' behavior is C99.

We need to remove the -xc99=%none from our option setting. It is time. Originally, this was used to try and make sure our source was C99 free, because at that time, not all C compilers we used had all the C99 features, and this was a way to make sure we stayed away from these features for the sake of portability. But that time has passed. We need to remove that option. It will just become increasingly more difficult going forward to avoid the use of C99 features with Solaris 11 and beyond. If there is not a bug filed already against java/build we should get one filed. -kto

On Sep 14, 2011, at 7:12 AM, Weijun Wang wrote: I meant http://bugs.sun.com/bugdatabase/viewbug.do?bugid=7090509.

-Max On 09/14/2011 10:08 PM, Weijun Wang wrote: I've filed a bug in solaris: xserver/libx11:

http://monaco.sfbay.sun.com/detail.jsf?cr=7090509 7090509 OpenJDK build failure on snv173 -Max

On 09/14/2011 08:57 PM, Chris Hegarty wrote: We came across a similar issue with SCTP a few months back, see CR 7051922 and CR 7051489. The Solaris guys fixed the header so that it did not use C99 features unless C99FEATURES is defined. -Chris. On 14/09/2011 12:25, Weijun Wang wrote: The machine is a snv173 and its /usr/include/X11/Xfuncproto.h is much longer than an old version, say, the one on sc11b1903, which is a JPRT machine with 5.10.

Here are the lines that causes the problem: 132 /* requires xproto >= 7.0.22 */ 133 #if defined(GNUC) && ((GNUC * 100 + GNUCMINOR) >= 303) 134 #define XNONNULL(args...) attribute((nonnull(args))) 135 #else 136 #define XNONNULL(...) /* */ 137 #endif So I write a tiny a.c and you can see: $ cat a.c #define A(...) int main() {} $ /java/devtools/sparc/SUNWspro/SS12u1/bin/cc a.c $ /java/devtools/sparc/SUNWspro/SS12u1/bin/cc -xc99=%none a.c "a.c", line 1: invalid token in #define macro parameters: ... cc: acomp failed for a.c -Max

On 09/14/2011 06:56 PM, Chris Hegarty wrote: Is it possible that one of the system includes in using C99 features? It may be that on older Solaris boxes have an older version of the include file? -Chris. On 14/09/2011 11:49, Weijun Wang wrote: I'm building jdk8 on a solaris-sparc and see this failure: /java/devtools/sparc/SUNWspro/SS12u1/bin/cc -xO2 -Wc,-Qrm-s -Wc,-Qiselect-T0 -L../../../build/solaris-sparc/tmp/sun/sun.awt/awt/obj -xc99=%none -xCC -errshort=tags -Xa -xregs=no%appl -xmemalign=4s -v -mt -xstrconst -W0,-noglobal -m32 -xarch=sparcvis -KPIC -D_MEDIALIBOLDNAMES -D_USEJ2DNAMES -DMLIBADDSUFF ../../../src/solaris/native/sun/awt/medialib/vis32.il -I../../../src/share/native/sun/awt/medialib -I../../../src/solaris/native/sun/awt/medialib -I../../../src/solaris/native/sun/java2d/loops -DNDEBUG -DTRIMMED -D_solaris -Dsparc -DTRACING -DMACROMEMSYSOPS -DBREAKPTS -I._ -I../../../build/solaris-sparc/tmp/sun/sun.awt/awt/CClassHeaders -I../../../src/solaris/javavm/export -I../../../src/share/javavm/export -I../../../src/share/native/common -I../../../src/solaris/native/common -I../../../src/share/native/sun/awt -I../../../src/solaris/native/sun/awt -I../../../src/share/native/sun/awt/debug -I../../../src/share/native/sun/awt/../font -I../../../src/solaris/native/sun/awt/../font -I../../../src/share/native/sun/awt/image -I../../../src/share/native/sun/awt/image/cvutils -I../../../src/share/native/sun/awt/shell -I../../../src/share/native/sun/awt/medialib -I../../../src/solaris/native/sun/awt/medialib -I../../../src/share/native/sun/awt/../java2d -I../../../src/solaris/native/sun/awt/../java2d -I../../../src/share/native/sun/awt/../java2d/loops -I../../../src/share/native/sun/awt/../java2d/pipe -I../../../src/share/native/sun/awt/../java2d/opengl -I../../../src/solaris/native/sun/awt/../java2d/opengl -I../../../src/solaris/native/sun/awt/../java2d/x11 -I../../../src/share/native/sun/awt/../dc/doe -I../../../src/share/native/sun/awt/../dc/path -I../../../src/solaris/native/sun/awt/../jdga -I../../../src/solaris/native/sun/awt -c -o ../../../build/solaris-sparc/tmp/sun/sun.awt/awt/obj/BufImgSurfaceData.o

../../../src/share/native/sun/awt/image/BufImgSurfaceData.c "/usr/include/X11/Xfuncproto.h", line 136: invalid token in #define macro parameters: ... cc: acomp failed for ../../../src/share/native/sun/awt/image/BufImgSurfaceData.c Googling "invalid token in #define macro parameters: ..." shows something about c99 so I remove the -xc99=%none option above and re-run the command and it succeeds. Is there really a connection here? The machine is pae-t4two-04. Thanks Max

More information about the build-dev mailing list