bug-glibc
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

gcc-3_0-branch, libc6 2.2.3-5(Debian) fails to build libjava


From: Gordon Sadler
Subject: gcc-3_0-branch, libc6 2.2.3-5(Debian) fails to build libjava
Date: Thu, 31 May 2001 13:05:06 -0500
User-agent: Mutt/1.3.18i

Sorry for the cross posting, but I feel this crosses a few boundaries.

I track Debian unstable here. This means I have a libc6 that is fairly
close to CVS HEAD. I also have a local CVS repo of libc, gcc-3.0, and
gcc. Last night libjava failed with:
/usr/local/src/build/gcc/gcc/g++ -B/usr/local/src/build/gcc/gcc/ -nostdinc++ 
-nostdinc++ -I/usr/local/src/build/gcc/i686-pc-linux-gnu/libstdc++-v3/include 
-I/usr/src/cvs/gcc/libstdc++-v3/include 
-I/usr/src/cvs/gcc/libstdc++-v3/include/std 
-I/usr/src/cvs/gcc/libstdc++-v3/include/c_std 
-I/usr/src/cvs/gcc/libstdc++-v3/libsupc++ -I/usr/src/cvs/gcc/libstdc++-v3/libio 
-I/usr/src/cvs/gcc/libstdc++-v3/testsuite 
-I/usr/src/cvs/gcc/libstdc++-v3/include/backwards 
-I/usr/src/cvs/gcc/libstdc++-v3/include/ext 
-L/usr/local/src/build/gcc/i686-pc-linux-gnu/libstdc++-v3/src 
-L/usr/local/src/build/gcc/i686-pc-linux-gnu/libstdc++-v3/src/.libs 
-B/usr/local/i686-pc-linux-gnu/bin/ -B/usr/local/i686-pc-linux-gnu/lib/ 
-isystem /usr/local/i686-pc-linux-gnu/include -DHAVE_CONFIG_H -I. 
-I/usr/src/cvs/gcc/libjava -I./include -I./gcj -I/usr/src/cvs/gcc/libjava 
-Iinclude -I/usr/src/cvs/gcc/libjava/include 
-I/usr/src/cvs/gcc/libjava/../boehm-gc/include -DLINUX_THREADS=1 -D_REENTRANT=1 
-DSILENT=1 -DNO_SIGNALS=1 -DJAVA_FINALIZATION=1 -DGC_GCJ_SUPPORT=1 
-I/usr/src/cvs/gcc/libjava/libltdl -I/usr/src/cvs/gcc/libjava/libltdl 
-I/usr/src/cvs/gcc/libjava/../gcc -I/usr/src/cvs/gcc/libjava/../libffi/include 
-I../libffi/include -fno-rtti -fnon-call-exceptions -fdollars-in-identifiers 
-D__NO_MATH_INLINES -ffloat-store -W -Wall -D_GNU_SOURCE -O2 -march=i686 
-D_GNU_SOURCE -Wp,-MD,.deps/natInetAddress.pp -c 
/usr/src/cvs/gcc/libjava/java/net/natInetAddress.cc  -fPIC -DPIC -o 
java/net/.libs/natInetAddress.o
In file included from /usr/src/cvs/gcc/libjava/java/net/natInetAddress.cc:42:
/usr/include/netdb.h:497: parse error before `]' token
make[3]: *** [java/net/natInetAddress.lo] Error 1

I've tracked this down to a recent change in libc:
RCS file: /cvs/glibc/libc/misc/sys/cdefs.h,v
Working file: misc/sys/cdefs.h
head: 1.44
branch:
locks: strict
access list:
keyword substitution: kv
total revisions: 44;    selected revisions: 1
description:
/* Copyright (C) 1992, 1993 Free Software Foundation, Inc.
----------------------------
revision 1.44
date: 2001/05/27 06:47:28;  author: drepper;  state: Exp;  lines: +15 -3
(__restrict_arr): Define appropriately for GCC 3.1 and non-GCC C99 compilers.
=============================================================================


cvs -f diff -bp -u -r1.43 -r1.44 misc/sys/cdefs.h
Index: misc/sys/cdefs.h
===================================================================
RCS file: /cvs/glibc/libc/misc/sys/cdefs.h,v
retrieving revision 1.43
retrieving revision 1.44
diff -b -p -u -r1.43 -r1.44
--- cdefs.h     2000/12/29 22:19:07     1.43
+++ cdefs.h     2001/05/27 06:47:28     1.44
@@ -195,8 +195,20 @@

 /* ISO C99 also allows to declare arrays as non-overlapping.  The syntax is
       array_name[restrict]
-   But gcc so far does not support this syntax.  We define a separate macro
-   for this which can be enabled if the underlying compiler supports it.  */
-#define __restrict_arr
+   GCC 3.1 supports this.  */
+#if __GNUC_PREREQ (3,1)
+# define __restrict_arr        __restrict
+#else
+# ifdef __GNUC__
+#  define __restrict_arr       /* Not supported in old GCC.  */
+# else
+#  if defined __STDC_VERSION__ && __STDC_VERSION__ >= 199901L
+#   define __restrict_arr      restrict
+#  else
+/* Some other non-C99 compiler.  */
+#   define __restrict_arr      /* Not supported.  */
+#  endif
+# endif
+#endif


So while building with gcc-3_0-branch __restrict_arr is undefined.

Possibly changing misc/sys/cdefs.h to define it for __GNUC_PREREQ (3,0)
would resolve this situation?


-- 
Gordon Sadler




reply via email to

[Prev in Thread] Current Thread [Next in Thread]