The error messages are:
../../gcc-4.3.5/gcc/toplev.c:545:1: error: redefinition of ‘floor_log2’ 545 | floor_log2 (unsigned HOST_WIDE_INT x) | ^~~~~~~~~~ In file included from ../../gcc-4.3.5/gcc/toplev.c:58: ../../gcc-4.3.5/gcc/toplev.h:177:1: note: previous definition of ‘floor_log2’ wa s here 177 | floor_log2 (unsigned HOST_WIDE_INT x) | ^~~~~~~~~~ ../../gcc-4.3.5/gcc/toplev.c:580:1: error: redefinition of ‘exact_log2’ 580 | exact_log2 (unsigned HOST_WIDE_INT x) | ^~~~~~~~~~ In file included from ../../gcc-4.3.5/gcc/toplev.c:58: ../../gcc-4.3.5/gcc/toplev.h:183:1: note: previous definition of ‘exact_log2’ wa s here 183 | exact_log2 (unsigned HOST_WIDE_INT x) | ^~~~~~~~~~
There is probably a GCC flag to allow such duplicate definitions, but I haven't found it yet (apparently, it isn't -Wnoduplicate-decl-specifier). I'm using the GCC 4.3.5 codebase and building with GCC 9.3.1 under Fedora 31 (x86_64).
I'm running configure as follows:
SRCDIR=../gcc-4.3.5 export CFLAGS ="-fkeep-inline-functions -W -Wall -Wwrite-strings \ -Wstrict-prototypes -Wmissing-prototypes \ -Wold-style-definition -Wmissing-format-attribute \ -pedantic -Wno-long-long -Wno-variadic-macros \ -Wno-overlength-strings -fno-common \ -Wnoduplicate-decl-specifier"
$SRCDIR/configure --program-suffix=-4.3.5 --disable-shared \ --enable-languages=pascal
The definition of CFLAGS was my attempt to allow the code to compile. It made no difference.
Any ideas as to how to proceed would be greatly appreciated.
John L. Ries 26215 197th Ave. SE Covington, WA 98042 (435) 867-8885
On May 10, 2020, at 7:18 PM, John Ries john@theyarnbard.com wrote:
The error messages are:
../../gcc-4.3.5/gcc/toplev.c:545:1: error: redefinition of ‘floor_log2’ 545 | floor_log2 (unsigned HOST_WIDE_INT x) | ^~~~~~~~~~ In file included from ../../gcc-4.3.5/gcc/toplev.c:58: ../../gcc-4.3.5/gcc/toplev.h:177:1: note: previous definition of ‘floor_log2’ wa s here 177 | floor_log2 (unsigned HOST_WIDE_INT x) | ^~~~~~~~~~ ../../gcc-4.3.5/gcc/toplev.c:580:1: error: redefinition of ‘exact_log2’ 580 | exact_log2 (unsigned HOST_WIDE_INT x) | ^~~~~~~~~~ In file included from ../../gcc-4.3.5/gcc/toplev.c:58: ../../gcc-4.3.5/gcc/toplev.h:183:1: note: previous definition of ‘exact_log2’ wa s here 183 | exact_log2 (unsigned HOST_WIDE_INT x) | ^~~~~~~~~~
There is probably a GCC flag to allow such duplicate definitions, but I haven't found it yet (apparently, it isn't -Wnoduplicate-decl-specifier). I'm using the GCC 4.3.5 codebase and building with GCC 9.3.1 under Fedora 31 (x86_64).
I'm running configure as follows:
SRCDIR=../gcc-4.3.5 export CFLAGS ="-fkeep-inline-functions -W -Wall -Wwrite-strings \ -Wstrict-prototypes -Wmissing-prototypes \ -Wold-style-definition -Wmissing-format-attribute \ -pedantic -Wno-long-long -Wno-variadic-macros \ -Wno-overlength-strings -fno-common \ -Wnoduplicate-decl-specifier"
$SRCDIR/configure --program-suffix=-4.3.5 --disable-shared \ --enable-languages=pascal
The definition of CFLAGS was my attempt to allow the code to compile. It made no difference.
Any ideas as to how to proceed would be greatly appreciated.
If you google on the error string "gcc/toplev.c:545:1: error: redefinition of ‘floor_log2’" you get amongst others a link to a link to a redhat bug report https://bugzilla.redhat.com/show_bug.cgi?id=476370 which states the fix is to use -fgnu89-inline along with the reasoning why you need to use it.
Not having tried it, I don't know if that's a good fix but it looks like something worth trying.
Gale Paeper gpaeper@empirenet.com
On Sun, May 10, 2020 at 07:18:01PM -0700, John Ries wrote:
The error messages are:
../../gcc-4.3.5/gcc/toplev.c:545:1: error: redefinition of ???floor_log2??? 545 | floor_log2 (unsigned HOST_WIDE_INT x) | ^~~~~~~~~~ In file included from ../../gcc-4.3.5/gcc/toplev.c:58: ../../gcc-4.3.5/gcc/toplev.h:177:1: note: previous definition of ???floor_log2??? wa s here 177 | floor_log2 (unsigned HOST_WIDE_INT x) | ^~~~~~~~~~ ../../gcc-4.3.5/gcc/toplev.c:580:1: error: redefinition of ???exact_log2??? 580 | exact_log2 (unsigned HOST_WIDE_INT x) | ^~~~~~~~~~ In file included from ../../gcc-4.3.5/gcc/toplev.c:58: ../../gcc-4.3.5/gcc/toplev.h:183:1: note: previous definition of ???exact_log2??? wa s here 183 | exact_log2 (unsigned HOST_WIDE_INT x) | ^~~~~~~~~~
There is probably a GCC flag to allow such duplicate definitions, but I haven't found it yet (apparently, it isn't -Wnoduplicate-decl-specifier). I'm using the GCC 4.3.5 codebase and building with GCC 9.3.1 under Fedora 31 (x86_64).
I'm running configure as follows:
SRCDIR=../gcc-4.3.5 export CFLAGS ="-fkeep-inline-functions -W -Wall -Wwrite-strings \ -Wstrict-prototypes -Wmissing-prototypes \ -Wold-style-definition -Wmissing-format-attribute \ -pedantic -Wno-long-long -Wno-variadic-macros \ -Wno-overlength-strings -fno-common \ -Wnoduplicate-decl-specifier"
$SRCDIR/configure --program-suffix=-4.3.5 --disable-shared \ --enable-languages=pascal
The definition of CFLAGS was my attempt to allow the code to compile. It made no difference.
Any ideas as to how to proceed would be greatly appreciated.
To compile with gcc-4.3.6 on Debian 10 I need two attached patches. First one fixes to problem above and a few other problems.
The second patch is a gross hack, to work around major breakage due to changes in Debian. Namely, Debian moved several critical files to archtecture specific subdirectories. For example, instead of
/usr/lib/crti.o
there is
/usr/lib/x86_64-linux-gnu/crti.o
(or analogous thing for different architecture). Notably, compilation of GPC is affected by location of C include files. If most C include files are in
/usr/include/x86_64-linux-gnu
then your system is affected. ATM I do not know which distributions use this scheme and which switched to Debian way. The second patch somewhat handles this issue. It is unstatisfactory, as it hardcodes 'x86_64-linux-gnu' and there is some (small ???) breakage when compiling C files (this affects mixed Pascal and C projects). Anyway, with both patches applied I can compile GPC on top of gcc-4.3.6 in Debian 10 using configure line:
../gcc-4.3.6.nn2/configure --enable-languages=c,pascal --disable-multilib --disable-mapped-location
Note that I always compile in directory separate from sources, that is reason for '../' at the start. '.nn2' suffix is to indicate that this is patched gcc (with two attached patches and gcc-4.3.5 patch).
Things have definitely improved. After applying sum1.diff (I'm running Fedora, which is not a Debian derivative), I was able to build gpc configured as follows:
SRCDIR=../gcc-4.3.5 $SRCDIR/configure --program-suffix=-4.3.5 --disable-shared \ --enable-languages=pascal --disable-multilib \ --disable-mapped-location
But when running "make check", I get the following:
cc -DHAVE_CONFIG_H -g -O2 -I.. -I../../../gcc-4.3.5/libiberty/testsuite/../../include -o test-demangle \ ../../../gcc-4.3.5/libiberty/testsuite/test-demangle.c ../libiberty.a ../../../gcc-4.3.5/libiberty/testsuite/test-demangle.c:49:1: error: conflicting types for ‘getline’ 49 | getline(buf) | ^~~~~~~ In file included from ../../../gcc-4.3.5/libiberty/testsuite/test-demangle.c:26: /usr/include/stdio.h:616:18: note: previous declaration of ‘getline’ was here 616 | extern __ssize_t getline (char **__restrict __lineptr, | ^~~~~~~ ../../../gcc-4.3.5/libiberty/testsuite/test-demangle.c: In function ‘protect_end’: ../../../gcc-4.3.5/libiberty/testsuite/test-demangle.c:105:21: warning: implicit declaration of function ‘getpagesize’ [-Wimplicit-function-declaration] 105 | size_t pagesize = getpagesize();
Cause for concern?
I am going to go ahead and install and see if I can build SAV.
John L. Ries 26215 197th Ave. SE Covington, WA 98042 (435) 867-8885
On Sat, May 16, 2020 at 6:34 AM Waldek Hebisch hebisch@math.uni.wroc.pl wrote:
On Sun, May 10, 2020 at 07:18:01PM -0700, John Ries wrote:
The error messages are:
../../gcc-4.3.5/gcc/toplev.c:545:1: error: redefinition of
???floor_log2???
545 | floor_log2 (unsigned HOST_WIDE_INT x) | ^~~~~~~~~~ In file included from ../../gcc-4.3.5/gcc/toplev.c:58: ../../gcc-4.3.5/gcc/toplev.h:177:1: note: previous definition of ???floor_log2??? wa s here 177 | floor_log2 (unsigned HOST_WIDE_INT x) | ^~~~~~~~~~ ../../gcc-4.3.5/gcc/toplev.c:580:1: error: redefinition of
???exact_log2???
580 | exact_log2 (unsigned HOST_WIDE_INT x) | ^~~~~~~~~~ In file included from ../../gcc-4.3.5/gcc/toplev.c:58: ../../gcc-4.3.5/gcc/toplev.h:183:1: note: previous definition of ???exact_log2??? wa s here 183 | exact_log2 (unsigned HOST_WIDE_INT x) | ^~~~~~~~~~
There is probably a GCC flag to allow such duplicate definitions, but I haven't found it yet (apparently, it isn't -Wnoduplicate-decl-specifier). I'm using the GCC 4.3.5 codebase and building with GCC 9.3.1 under Fedora 31 (x86_64).
I'm running configure as follows:
SRCDIR=../gcc-4.3.5 export CFLAGS ="-fkeep-inline-functions -W -Wall -Wwrite-strings \ -Wstrict-prototypes -Wmissing-prototypes \ -Wold-style-definition -Wmissing-format-attribute \ -pedantic -Wno-long-long -Wno-variadic-macros \ -Wno-overlength-strings -fno-common \ -Wnoduplicate-decl-specifier"
$SRCDIR/configure --program-suffix=-4.3.5 --disable-shared \ --enable-languages=pascal
The definition of CFLAGS was my attempt to allow the code to compile. It made no difference.
Any ideas as to how to proceed would be greatly appreciated.
To compile with gcc-4.3.6 on Debian 10 I need two attached patches. First one fixes to problem above and a few other problems.
The second patch is a gross hack, to work around major breakage due to changes in Debian. Namely, Debian moved several critical files to archtecture specific subdirectories. For example, instead of
/usr/lib/crti.o
there is
/usr/lib/x86_64-linux-gnu/crti.o
(or analogous thing for different architecture). Notably, compilation of GPC is affected by location of C include files. If most C include files are in
/usr/include/x86_64-linux-gnu
then your system is affected. ATM I do not know which distributions use this scheme and which switched to Debian way. The second patch somewhat handles this issue. It is unstatisfactory, as it hardcodes 'x86_64-linux-gnu' and there is some (small ???) breakage when compiling C files (this affects mixed Pascal and C projects). Anyway, with both patches applied I can compile GPC on top of gcc-4.3.6 in Debian 10 using configure line:
../gcc-4.3.6.nn2/configure --enable-languages=c,pascal --disable-multilib --disable-mapped-location
Note that I always compile in directory separate from sources, that is reason for '../' at the start. '.nn2' suffix is to indicate that this is patched gcc (with two attached patches and gcc-4.3.5 patch).
-- Waldek Hebisch
Well. that didn't work. I get:
gpc-4.3.5 -c queues.p gpc-4.3.5 -c ranklist.p gpc-4.3.5 -o sav sav.p /usr/bin/ld: cannot find -lgpc collect2: ld returned 1 exit status
The only libgpc.a I see is from the GPC I built in 2014, so something is definitely wrong. I'll work in this some more later; but in the mean time, any ideas?
John L. Ries 26215 197th Ave. SE Covington, WA 98042 (435) 867-8885
On Sat, May 16, 2020 at 1:55 PM John Ries john@theyarnbard.com wrote:
Things have definitely improved. After applying sum1.diff (I'm running Fedora, which is not a Debian derivative), I was able to build gpc configured as follows:
SRCDIR=../gcc-4.3.5 $SRCDIR/configure --program-suffix=-4.3.5 --disable-shared \ --enable-languages=pascal --disable-multilib \ --disable-mapped-location
But when running "make check", I get the following:
cc -DHAVE_CONFIG_H -g -O2 -I.. -I../../../gcc-4.3.5/libiberty/testsuite/../../include -o test-demangle \ ../../../gcc-4.3.5/libiberty/testsuite/test-demangle.c ../libiberty.a ../../../gcc-4.3.5/libiberty/testsuite/test-demangle.c:49:1: error: conflicting types for ‘getline’ 49 | getline(buf) | ^~~~~~~ In file included from ../../../gcc-4.3.5/libiberty/testsuite/test-demangle.c:26: /usr/include/stdio.h:616:18: note: previous declaration of ‘getline’ was here 616 | extern __ssize_t getline (char **__restrict __lineptr, | ^~~~~~~ ../../../gcc-4.3.5/libiberty/testsuite/test-demangle.c: In function ‘protect_end’: ../../../gcc-4.3.5/libiberty/testsuite/test-demangle.c:105:21: warning: implicit declaration of function ‘getpagesize’ [-Wimplicit-function-declaration] 105 | size_t pagesize = getpagesize();
Cause for concern?
I am going to go ahead and install and see if I can build SAV.
John L. Ries 26215 197th Ave. SE Covington, WA 98042 (435) 867-8885
On Sat, May 16, 2020 at 6:34 AM Waldek Hebisch hebisch@math.uni.wroc.pl wrote:
On Sun, May 10, 2020 at 07:18:01PM -0700, John Ries wrote:
The error messages are:
../../gcc-4.3.5/gcc/toplev.c:545:1: error: redefinition of
???floor_log2???
545 | floor_log2 (unsigned HOST_WIDE_INT x) | ^~~~~~~~~~ In file included from ../../gcc-4.3.5/gcc/toplev.c:58: ../../gcc-4.3.5/gcc/toplev.h:177:1: note: previous definition of ???floor_log2??? wa s here 177 | floor_log2 (unsigned HOST_WIDE_INT x) | ^~~~~~~~~~ ../../gcc-4.3.5/gcc/toplev.c:580:1: error: redefinition of
???exact_log2???
580 | exact_log2 (unsigned HOST_WIDE_INT x) | ^~~~~~~~~~ In file included from ../../gcc-4.3.5/gcc/toplev.c:58: ../../gcc-4.3.5/gcc/toplev.h:183:1: note: previous definition of ???exact_log2??? wa s here 183 | exact_log2 (unsigned HOST_WIDE_INT x) | ^~~~~~~~~~
There is probably a GCC flag to allow such duplicate definitions, but I haven't found it yet (apparently, it isn't
-Wnoduplicate-decl-specifier).
I'm using the GCC 4.3.5 codebase and building with GCC 9.3.1 under
Fedora
31 (x86_64).
I'm running configure as follows:
SRCDIR=../gcc-4.3.5 export CFLAGS ="-fkeep-inline-functions -W -Wall -Wwrite-strings \ -Wstrict-prototypes -Wmissing-prototypes \ -Wold-style-definition -Wmissing-format-attribute \ -pedantic -Wno-long-long -Wno-variadic-macros \ -Wno-overlength-strings -fno-common \ -Wnoduplicate-decl-specifier"
$SRCDIR/configure --program-suffix=-4.3.5 --disable-shared \ --enable-languages=pascal
The definition of CFLAGS was my attempt to allow the code to compile.
It
made no difference.
Any ideas as to how to proceed would be greatly appreciated.
To compile with gcc-4.3.6 on Debian 10 I need two attached patches. First one fixes to problem above and a few other problems.
The second patch is a gross hack, to work around major breakage due to changes in Debian. Namely, Debian moved several critical files to archtecture specific subdirectories. For example, instead of
/usr/lib/crti.o
there is
/usr/lib/x86_64-linux-gnu/crti.o
(or analogous thing for different architecture). Notably, compilation of GPC is affected by location of C include files. If most C include files are in
/usr/include/x86_64-linux-gnu
then your system is affected. ATM I do not know which distributions use this scheme and which switched to Debian way. The second patch somewhat handles this issue. It is unstatisfactory, as it hardcodes 'x86_64-linux-gnu' and there is some (small ???) breakage when compiling C files (this affects mixed Pascal and C projects). Anyway, with both patches applied I can compile GPC on top of gcc-4.3.6 in Debian 10 using configure line:
../gcc-4.3.6.nn2/configure --enable-languages=c,pascal --disable-multilib --disable-mapped-location
Note that I always compile in directory separate from sources, that is reason for '../' at the start. '.nn2' suffix is to indicate that this is patched gcc (with two attached patches and gcc-4.3.5 patch).
-- Waldek Hebisch
On Sat, May 16, 2020 at 02:49:47PM -0700, John Ries wrote:
Well. that didn't work. I get:
gpc-4.3.5 -c queues.p gpc-4.3.5 -c ranklist.p gpc-4.3.5 -o sav sav.p /usr/bin/ld: cannot find -lgpc collect2: ld returned 1 exit status
The only libgpc.a I see is from the GPC I built in 2014, so something is definitely wrong. I'll work in this some more later; but in the mean time, any ideas?
You should see 'libgpc.a' in the 'x86_64-unknown-linux-gnu/libgpc/p/rts' subdirectory of the build tree.
On my machine (from build directory):
ls x86_64-unknown-linux-gnu/libgpc/p/rts/ Makefile fname.gpi gpc_ep.gpi random.gpi string1.gpi config.cache fname.o heap.gpi random.o string1.o config.log getopt.gpi heap.o rts-config.h string2.gpi config.status getopt.o init.gpi rts-config.inc string2.o endian.gpi gpc-all.gpi init.o rts.o time.gpi endian.o gpc.gpi libgpc.a rtsc.gpi time.o error.gpi gpc.o math.gpi rtsc.o error.o gpc_bp.gpi math.o sets.gpi files.gpi gpc_cp.gpi move.gpi sets.o files.o gpc_delphi.gpi move.o stamp-error-gpi
On Sat, May 16, 2020 at 01:55:01PM -0700, John Ries wrote:
Things have definitely improved. After applying sum1.diff (I'm running Fedora, which is not a Debian derivative), I was able to build gpc configured as follows:
SRCDIR=../gcc-4.3.5 $SRCDIR/configure --program-suffix=-4.3.5 --disable-shared \ --enable-languages=pascal --disable-multilib \ --disable-mapped-location
You wrote that you are running Fedora, so I knew that. I do not know what is Fedora position concerning moving locations of system files. IIUC Debian changes were result of a proposal supposedly having wide support. I do not know if Fedora decided that they will not make the changes or if they made change preserving backwards compatibility. In the second case this may be a time bomb, some day they may decide that backwards compatibility is no longer needed.
But when running "make check", I get the following:
cc -DHAVE_CONFIG_H -g -O2 -I.. -I../../../gcc-4.3.5/libiberty/testsuite/../../include -o test-demangle \ ../../../gcc-4.3.5/libiberty/testsuite/test-demangle.c ../libiberty.a ../../../gcc-4.3.5/libiberty/testsuite/test-demangle.c:49:1: error: conflicting types for ???getline??? 49 | getline(buf) | ^~~~~~~ In file included from ../../../gcc-4.3.5/libiberty/testsuite/test-demangle.c:26: /usr/include/stdio.h:616:18: note: previous declaration of ???getline??? was here 616 | extern __ssize_t getline (char **__restrict __lineptr, | ^~~~~~~ ../../../gcc-4.3.5/libiberty/testsuite/test-demangle.c: In function ???protect_end???: ../../../gcc-4.3.5/libiberty/testsuite/test-demangle.c:105:21: warning: implicit declaration of function ???getpagesize??? [-Wimplicit-function-declaration] 105 | size_t pagesize = getpagesize();
Cause for concern?
The above alone is no reason to worry. GCC testsuite contains a lot The above looks like test program which makes assumption about system header files which are no longer valid. GCC testsuite contains a lot of test programs, and if one of them has such problem there is no reason to worry.
More relevant for you is GPC testsuite. I do not remember if GCC 'make check' runs Pascal tests. I normally run Pascal tests chacging directory to 'gcc' subdirectory of build tree and typing
make pascal.check-long > ../chk_logg 2>&1
Note: the results take several screens so I use redirection to catch them in file. With gcc-4.x.x testsuite will fail if run immediately after build. Either install before running testsuite or copy 'libgpc.a' from libgpc build directory to gcc subdirectory and copy rts-confing.inc from libgpc build directory to gcc/p/rts subdirectory (you need to create rts subdirectiry).
I normally do the second (copy files needed to run testsuite).
-
Gale Paeper -
John Ries -
Waldek Hebisch