> 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/view_bug.do?bug_id=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 snv_173
-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 snv_173 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 + __GNUC_MINOR__) >= 303)
134 #define _X_NONNULL(args...) __attribute__((nonnull(args)))
135 #else
136 #define _X_NONNULL(...) /* */
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__MEDIALIB_OLD_NAMES -D__USE_J2D_NAMES -DMLIB_ADD_SUFF
../../../src/solaris/native/sun/awt/medialib/vis_32.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 -DMACRO_MEMSYS_OPS -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
