Hi
compiled & installed bison 1.875c, make check reported 7 errors. Traced problem to error in gcc-3.4: the default install of /usr/local puts libstdc++ in /usr/local/lib but the gcc code expects it to be in /usr/lib. Rebuilt gcc & installed using --prefix=/usr. Rebuilt bison & installed. Now make check reports all ok.
So back to the patched version of gcc-3.4:
rm -r * in the build directory to start clean.
make -j3 bootstrap - it failed in p then "make bootstrap > emsgs 2>&1" last few lines are:
gcc -o p/parse.o -c -g -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -DHAVE_CONFIG_H -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -I. -Ip -I../../gcc-3.4.0/gcc -I../../gcc-3.4.0/gcc/p -I../../gcc-3.4.0/gcc/../include -DGPC -I../../gcc-3.4.0/gcc/p ../../gcc-3.4.0/gcc/p/parse.c parse.c:378: warning: useless keyword or type name in empty declaration parse.c:378: warning: empty declaration parse.c: In function `yydoAction': parse.c:8133: error: `USE_ASSERT_RATHER_THAN_ABORT' undeclared (first use in this function) parse.c:8133: error: (Each undeclared identifier is reported only once parse.c:8133: error: for each function it appears in.) parse.c: In function `yyglrReduce': parse.c:8249: error: `USE_ASSERT_RATHER_THAN_ABORT' undeclared (first use in this function) parse.c: In function `yysplitStack': parse.c:8287: error: `USE_ASSERT_RATHER_THAN_ABORT' undeclared (first use in this function) parse.c: In function `yyresolveStates': parse.c:8386: error: `USE_ASSERT_RATHER_THAN_ABORT' undeclared (first use in this function) parse.c: In function `yyresolveAction': parse.c:8417: error: `USE_ASSERT_RATHER_THAN_ABORT' undeclared (first use in this function) parse.c: In function `yyprocessOneStack': parse.c:8610: error: `USE_ASSERT_RATHER_THAN_ABORT' undeclared (first use in this function) parse.y: At top level: parse.y:2967: warning: 'locations' defined but not used make[2]: *** [p/parse.o] Error 1 make[2]: Leaving directory `/home/russ/src/gpc-20030830-3.4.0/build/gcc' make[1]: *** [stage1_build] Error 2 make[1]: Leaving directory `/home/russ/src/gpc-20030830-3.4.0/build/gcc' make: *** [bootstrap] Error 2
h'm looks like same problem last email.
Russ
Russell Whitaker wrote:
So back to the patched version of gcc-3.4:
rm -r * in the build directory to start clean.
h'm looks like same problem last email.
Bison output files parse.[ch] are generated in the source directory. Try removing these.
Frank
On Sat, 24 Apr 2004, Frank Heckenbach wrote:
Russell Whitaker wrote:
So back to the patched version of gcc-3.4:
rm -r * in the build directory to start clean.
h'm looks like same problem last email.
Bison output files parse.[ch] are generated in the source directory. Try removing these.
Thanks, that worked.
Next problem I did a quick fix:
*** p/rts/rts.c.orig Fri Apr 23 14:10:54 2004 --- p/rts/rts.c Sat Apr 24 07:07:59 2004 *************** extern char **__environ; *** 207,214 **** #endif ! ! #if defined (HAVE_SYS_SIGLIST) || defined (sys_siglist) ! #if !defined (sys_siglist) && !defined (SYS_SIGLIST_DECLARED) ! extern char **sys_siglist; ! #endif ! #elif defined (HAVE__SYS_SIGLIST) || defined (_sys_siglist) #if !defined (_sys_siglist) && !defined (_SYS_SIGLIST_DECLARED) --- 207,210 ---- #endif ! ! #if defined (HAVE__SYS_SIGLIST) || defined (_sys_siglist) #if !defined (_sys_siglist) && !defined (_SYS_SIGLIST_DECLARED)
The original define of sys_siglist is line 285, /usr/include/signal.h
Test results: skip 3, all the rest passed.
One last (small) problem: --automake seems to be "semi-broken". Had to import the module/unit source into the current directory otherwise got "module/unit ... could not be compiled" when compiling something with a uses clause.
Russ
Russell Whitaker wrote:
One last (small) problem: --automake seems to be "semi-broken". Had to import the module/unit source into the current directory otherwise got "module/unit ... could not be compiled" when compiling something with a uses clause.
Yes, I noticed the same on apple-powerpc-darwin.
Regards,
Adriaan van Os
Russell Whitaker wrote:
One last (small) problem: --automake seems to be "semi-broken". Had to import the module/unit source into the current directory otherwise got "module/unit ... could not be compiled" when compiling something with a uses clause.
AFAIKS `--automake' just can not find units. gcc-3.4 uses different directory layout, with default prefix gpc1 goes into
/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/3.4.0/
but units go into
/usr/local/lib/gcc/x86_64-unknown-linux-gnu/3.4.0/units
gpc is searching for units in
/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/3.4.0/units
quick fix is to give '--unit-path=' option (or copy the units directory), but in long them we must teach gpc about new location.
On Sat, 24 Apr 2004, Waldek Hebisch wrote:
Russell Whitaker wrote:
One last (small) problem: --automake seems to be "semi-broken". Had to import the module/unit source into the current directory otherwise got "module/unit ... could not be compiled" when compiling something with a uses clause.
AFAIKS `--automake' just can not find units. gcc-3.4 uses different directory layout, with default prefix gpc1 goes into
/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/3.4.0/
but units go into
/usr/local/lib/gcc/x86_64-unknown-linux-gnu/3.4.0/units
gpc is searching for units in
/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/3.4.0/units
quick fix is to give '--unit-path=' option (or copy the units directory), but in long them we must teach gpc about new location.
Just now tried this - (my gcc install used --prefix=/usr because of a c++ problem ):
in directory /usr/libexec/gcc/i686-pc-linux-gnu/3.4.0 added ln -s ../../../../lib/gcc/i686-pc-linux-gnu/3.4.0/units units and --automake now works.
Thanks Russ
Russell Whitaker wrote:
Next problem I did a quick fix:
*** p/rts/rts.c.orig Fri Apr 23 14:10:54 2004 --- p/rts/rts.c Sat Apr 24 07:07:59 2004 *************** extern char **__environ; *** 207,214 **** #endif ! ! #if defined (HAVE_SYS_SIGLIST) || defined (sys_siglist) ! #if !defined (sys_siglist) && !defined (SYS_SIGLIST_DECLARED) ! extern char **sys_siglist; ! #endif ! #elif defined (HAVE__SYS_SIGLIST) || defined (_sys_siglist) #if !defined (_sys_siglist) && !defined (_SYS_SIGLIST_DECLARED) --- 207,210 ---- #endif ! ! #if defined (HAVE__SYS_SIGLIST) || defined (_sys_siglist) #if !defined (_sys_siglist) && !defined (_SYS_SIGLIST_DECLARED)
The original define of sys_siglist is line 285, /usr/include/signal.h
Is this a `#define'? If so, there's something seriously wrong, since the code you removed says `#if !defined (sys_siglist)'.
If it's a declaration instead, it looks like a problem with configure (SYS_SIGLIST_DECLARED should be set). I can't debug this now.
Frank
On Sun, 25 Apr 2004, Frank Heckenbach wrote:
Russell Whitaker wrote:
Next problem I did a quick fix:
[..]
Is this a `#define'? If so, there's something seriously wrong, since the code you removed says `#if !defined (sys_siglist)'.
If it's a declaration instead, it looks like a problem with configure (SYS_SIGLIST_DECLARED should be set). I can't debug this now.
This is a snipet from /usr/include/signal.h :
#ifdef __USE_BSD
/* Names of the signals. This variable exists only for compatibility. Use `strsignal' instead (see <string.h>). */ extern __const char *__const _sys_siglist[_NSIG]; <----line 285 extern __const char *__const sys_siglist[_NSIG];
And this is a snipet from p/rts/rts.c :
#if defined (HAVE_SYS_SIGLIST) || defined (sys_siglist) #if !defined (sys_siglist) && !defined (SYS_SIGLIST_DECLARED) extern char **sys_siglist; <----line 211 #endif #elif defined (HAVE__SYS_SIGLIST) || defined (_sys_siglist) #if !defined (_sys_siglist) && !defined (_SYS_SIGLIST_DECLARED) extern char **_sys_siglist; #endif #define sys_siglist _sys_siglist #endif
The build complained about line 211 being previously defined ( at line 285 in /usr/include/signal.h ). Thought lines 210 and 214 should have the "&& !defined ( ... " removed, but I do not know what else needs to be done to the rest of the snipet to be a universal fix. So I did a quick and dirty "it works here" fix and let you decide what you want to do.
Russ
Russell Whitaker wrote:
On Sun, 25 Apr 2004, Frank Heckenbach wrote:
Russell Whitaker wrote:
Next problem I did a quick fix:
[..]
Is this a `#define'? If so, there's something seriously wrong, since the code you removed says `#if !defined (sys_siglist)'.
If it's a declaration instead, it looks like a problem with configure (SYS_SIGLIST_DECLARED should be set). I can't debug this now.
This is a snipet from /usr/include/signal.h :
#ifdef __USE_BSD
/* Names of the signals. This variable exists only for compatibility. Use `strsignal' instead (see <string.h>). */ extern __const char *__const _sys_siglist[_NSIG]; <----line 285 extern __const char *__const sys_siglist[_NSIG];
And this is a snipet from p/rts/rts.c :
#if defined (HAVE_SYS_SIGLIST) || defined (sys_siglist) #if !defined (sys_siglist) && !defined (SYS_SIGLIST_DECLARED) extern char **sys_siglist; <----line 211 #endif #elif defined (HAVE__SYS_SIGLIST) || defined (_sys_siglist) #if !defined (_sys_siglist) && !defined (_SYS_SIGLIST_DECLARED) extern char **_sys_siglist; #endif #define sys_siglist _sys_siglist #endif
The build complained about line 211 being previously defined ( at line 285 in /usr/include/signal.h ). Thought lines 210 and 214 should have the "&& !defined ( ... " removed, but I do not know what else needs to be done to the rest of the snipet to be a universal fix.
Why do you think so? Since your signal.h does declare the variable, SYS_SIGLIST_DECLARED should have been set by configure, so `!defined' (for our redeclaration) seems correct.
Apparently SYS_SIGLIST_DECLARED is not set (you can check in rts-config.h in the build dir) which would be a configure problem as I said.
Frank