Hi Folks,
the good news about the 20011123 version under IRIX 6.5 is that it compiles without problems and no test fails with the 20011123 test kit. The writeln works properly thanks to the --big-endian trick of Frank.
The bad news are:
- the kit won't compile with the native sed/grep but with the GNU versions only.
- the produced binary still leaks memory on string operations unless they are in the procedures.
- the -static switch is broken. Here is the log with the -v switch:
Reading specs from /var/tmp/gpc/lib/gcc-lib/mips-sgi-irix6.5/2.95.2/specs gpc version 20011123, based on 2.95.2 19991024 (release) /var/tmp/gpc/lib/gcc-lib/mips-sgi-irix6.5/2.95.2/gpcpp -lang-pascal -v -I/home/pugh/miklos/src -famtmpfile=/var/tmp/cca00jWd -fbig-endian -fdelphi-comments -D__GNU_PASCAL__ -undef -D__GNUC__=2 -D__GNUC_MINOR__=95 -D__GPC__=2 -D__GPC_MINOR__=0 -D__GPC_VERSION__=2.0 -D__GPC_RELEASE__=20011123 -D__BITS_BIG_ENDIAN__=1 -D__BYTES_BIG_ENDIAN__=1 -D__WORDS_BIG_ENDIAN__=1 -D__NEED_ALIGNMENT__=1 -Dunix -Dmips -Dsgi -Dhost_mips -DMIPSEB -D_MIPSEB -DSYSTYPE_SVR4 -D_LONGLONG -D_SVR4_SOURCE -D_MODERN_C -D__DSO__ -D__unix__ -D__mips__ -D__sgi__ -D__host_mips__ -D__MIPSEB__ -D_MIPSEB -D__SYSTYPE_SVR4__ -D_LONGLONG -D_SVR4_SOURCE -D_MODERN_C -D__DSO__ -D__unix -D__mips -D__sgi -D__host_mips -D__MIPSEB -D__SYSTYPE_SVR4 -Asystem(unix) -Asystem(svr4) -Acpu(mips) -Amachine(sgi) -D__CHAR_UNSIGNED__ -D__OPTIMIZE__ -D__LANGUAGE_C -D_LANGUAGE_C -DLANGUAGE_C -D__SIZE_TYPE__=unsigned int -D__PTRDIFF_TYPE__=int -D__EXTENSIONS__ -D_SGI_SOURCE -D_MIPS_FPSET=32 -D_MIPS_ISA=_MIPS_ISA_MIPS3 -D_ABIN32=2 -D_MIPS_SIM=_ABIN32 -D_MIPS_SZINT=32 -D_MIPS_SZLONG=32 -D_MIPS_SZPTR=32 -D_COMPILER_VERSION=601 -U__mips -D__mips=3 -D__mips64 das.p /var/tmp/cca00jWd.i GNU Pascal Compiler PreProcessor version 20011123, based on gcc-2.95.2 19991024 (release) [AL 1.1, MM 40] SGI running IRIX 6.x #include "..." search starts here: #include <...> search starts here: /home/pugh/miklos/src /var/tmp/gpc/include /var/tmp/gpc/mips-sgi-irix6.5/include /var/tmp/gpc/lib/gcc-lib/mips-sgi-irix6.5/2.95.2/include /usr/include End of search list. /var/tmp/gpc/lib/gcc-lib/mips-sgi-irix6.5/2.95.2/gpc1 /var/tmp/cca00jWd.i -mno-abicalls -quiet -dumpbase das.pas -O -version -famtmpfile=/var/tmp/cca00jWd -fbig-endian -o /var/tmp/cca00jWd.s GNU Pascal version 2.95.2 19991024 (release) (mips-sgi-irix6.5) compiled by GNU C version egcs-2.91.66 19990314 (egcs-1.1.2 release). GNU Pascal version is actually 20011123, based on gcc-2.95.2 19991024 (release) /usr/bin/as -O2 -g0 -nocpp -show -G 0 -w -n32 -o /var/tmp/cca00jWd1.o /var/tmp/cca00jWd.s /usr/bin/../../usr/lib32/cmplrs/as -DEFAULT:abi=n32:isa=mips4:proc=r10k -O2 -g0 -nocpp -show -G 0 -w -n32 -o /var/tmp/cca00jWd1.o /var/tmp/cca00jWd.s /usr/lib32/cmplrs/asm -t5_ll_sc_bug -EB -pic2 -elf -O2 -g0 -G0 -w -mips4 -n32 /var/tmp/cca00jWd.s -o /var/tmp/cca00jWd1.o /var/tmp/gpc/lib/gcc-lib/mips-sgi-irix6.5/2.95.2/collect2 -non_shared -init __do_global_ctors -fini __do_global_dtors -_SYSTYPE_SVR4 -woff 131 -n32 -o das.sgi /usr/lib32/mips3/nonshared/crt1.o /var/tmp/gpc/lib/gcc-lib/mips-sgi-irix6.5/2.95.2/crtbegin.o -L/var/tmp/gpc/lib/gcc-lib/mips-sgi-irix6.5/2.95.2 -L/usr/bin -L/var/tmp/gpc/lib /var/tmp/cca00jWd1.o -lgpc -lm -dont_warn_unused -lgcc -warn_unused -L/usr/lib32/mips3 -L/usr/lib32 -dont_warn_unused -lc -warn_unused -dont_warn_unused -lgcc -warn_unused /var/tmp/gpc/lib/gcc-lib/mips-sgi-irix6.5/2.95.2/crtend.o /usr/lib32/mips3/crtn.o ld32: FATAL 9 : I/O error (/usr/lib32/mips3/nonshared/crt1.o): No such file or directory collect2: ld returned 32 exit status
The crt1.o is actually in /usr/lib32/mips3. The /usr/lib32/mips3/nonshared is not exist. What is the civilized way to tell the compiler where to look for the proper objects? (Other than set up a symlink and fool the compiler.)
Nice work otherwise, cheers,
miklos
Miklos Cserzo wrote:
- the kit won't compile with the native sed/grep but with the GNU
versions only.
What exactly happens with the native tools?
- the produced binary still leaks memory on string operations unless they
are in the procedures.
Stack memory, I suppose (i.e., memory is regained when leaving the routine). Yes, that's a known bug.
- the -static switch is broken. Here is the log with the -v switch:
Reading specs from /var/tmp/gpc/lib/gcc-lib/mips-sgi-irix6.5/2.95.2/specs gpc version 20011123, based on 2.95.2 19991024 (release) /var/tmp/gpc/lib/gcc-lib/mips-sgi-irix6.5/2.95.2/gpcpp -lang-pascal -v -I/home/pugh/miklos/src -famtmpfile=/var/tmp/cca00jWd -fbig-endian -fdelphi-comments -D__GNU_PASCAL__ -undef -D__GNUC__=2 -D__GNUC_MINOR__=95 -D__GPC__=2 -D__GPC_MINOR__=0 -D__GPC_VERSION__=2.0 -D__GPC_RELEASE__=20011123 -D__BITS_BIG_ENDIAN__=1 -D__BYTES_BIG_ENDIAN__=1 -D__WORDS_BIG_ENDIAN__=1 -D__NEED_ALIGNMENT__=1 -Dunix -Dmips -Dsgi -Dhost_mips -DMIPSEB -D_MIPSEB -DSYSTYPE_SVR4 -D_LONGLONG -D_SVR4_SOURCE -D_MODERN_C -D__DSO__ -D__unix__ -D__mips__ -D__sgi__ -D__host_mips__ -D__MIPSEB__ -D_MIPSEB -D__SYSTYPE_SVR4__ -D_LONGLONG -D_SVR4_SOURCE -D_MODERN_C -D__DSO__ -D__unix -D__mips -D__sgi -D__host_mips -D__MIPSEB -D__SYSTYPE_SVR4 -Asystem(unix) -Asystem(svr4) -Acpu(mips) -Amachine(sgi) -D__CHAR_UNSIGNED__ -D__OPTIMIZE__ -D__LANGUAGE_C -D_LANGUAGE_C -DLANGUAGE_C -D__SIZE_TYPE__=unsigned int -D__PTRDIFF_TYPE__=int -D__EXTENSIONS__ -D_SGI_SOURCE -D_MIPS_FPSET=32 -D_MIPS_ISA=_MIPS_ISA_MIPS3 -D_ABIN32=2 -D_MIPS_SIM=_ABIN32 -D_MIPS_SZINT=32 -D_MIPS_SZLONG=32 -D_MIPS_SZPTR=32 -D_COMPILER_VERSION=601 -U__mips -D__mips=3 -D__mips64 das.p /var/tmp/cca00jWd.i GNU Pascal Compiler PreProcessor version 20011123, based on gcc-2.95.2 19991024 (release) [AL 1.1, MM 40] SGI running IRIX 6.x #include "..." search starts here: #include <...> search starts here: /home/pugh/miklos/src /var/tmp/gpc/include /var/tmp/gpc/mips-sgi-irix6.5/include /var/tmp/gpc/lib/gcc-lib/mips-sgi-irix6.5/2.95.2/include /usr/include End of search list. /var/tmp/gpc/lib/gcc-lib/mips-sgi-irix6.5/2.95.2/gpc1 /var/tmp/cca00jWd.i -mno-abicalls -quiet -dumpbase das.pas -O -version -famtmpfile=/var/tmp/cca00jWd -fbig-endian -o /var/tmp/cca00jWd.s GNU Pascal version 2.95.2 19991024 (release) (mips-sgi-irix6.5) compiled by GNU C version egcs-2.91.66 19990314 (egcs-1.1.2 release). GNU Pascal version is actually 20011123, based on gcc-2.95.2 19991024 (release) /usr/bin/as -O2 -g0 -nocpp -show -G 0 -w -n32 -o /var/tmp/cca00jWd1.o /var/tmp/cca00jWd.s /usr/bin/../../usr/lib32/cmplrs/as -DEFAULT:abi=n32:isa=mips4:proc=r10k -O2 -g0 -nocpp -show -G 0 -w -n32 -o /var/tmp/cca00jWd1.o /var/tmp/cca00jWd.s /usr/lib32/cmplrs/asm -t5_ll_sc_bug -EB -pic2 -elf -O2 -g0 -G0 -w -mips4 -n32 /var/tmp/cca00jWd.s -o /var/tmp/cca00jWd1.o /var/tmp/gpc/lib/gcc-lib/mips-sgi-irix6.5/2.95.2/collect2 -non_shared -init __do_global_ctors -fini __do_global_dtors -_SYSTYPE_SVR4 -woff 131 -n32 -o das.sgi /usr/lib32/mips3/nonshared/crt1.o /var/tmp/gpc/lib/gcc-lib/mips-sgi-irix6.5/2.95.2/crtbegin.o -L/var/tmp/gpc/lib/gcc-lib/mips-sgi-irix6.5/2.95.2 -L/usr/bin -L/var/tmp/gpc/lib /var/tmp/cca00jWd1.o -lgpc -lm -dont_warn_unused -lgcc -warn_unused -L/usr/lib32/mips3 -L/usr/lib32 -dont_warn_unused -lc -warn_unused -dont_warn_unused -lgcc -warn_unused /var/tmp/gpc/lib/gcc-lib/mips-sgi-irix6.5/2.95.2/crtend.o /usr/lib32/mips3/crtn.o ld32: FATAL 9 : I/O error (/usr/lib32/mips3/nonshared/crt1.o): No such file or directory collect2: ld returned 32 exit status
The crt1.o is actually in /usr/lib32/mips3. The /usr/lib32/mips3/nonshared is not exist. What is the civilized way to tell the compiler where to look for the proper objects? (Other than set up a symlink and fool the compiler.)
Perhaps editing the specs -- the string `nonshared' appears only in ../config/mips/iris*.h, so I suppose it's something IRIX specific. Maybe the location was changed in some version.
But wait, perhaps this /usr/lib32/mips3/crt1.o is in fact not a static version, and you'll have to install a static version in /usr/lib32/mips3/nonshared in the first place (since GCC doesn't seem to install it, maybe it's part of the OS -- I don't know what IRIX installation is like, but on Linux I'd say you'd have to install packages for static runtime library support or similar).
BTW, does `gcc -static' work? If so, you might want to compare its `-v' output with GPC's and find out what the difference is.
Frank
On Sat, 8 Dec 2001, Frank Heckenbach wrote:
What exactly happens with the native tools?
Here is the log (the whole lot):
make CFLAGS=-O2 if [ x"no" = xyes ] && [ ! -d pic ]; then \ mkdir pic; \ else true; fi touch stamp-picdir test x"no" != xyes || \ gcc -c -DHAVE_CONFIG_H -O2 -I. -I/home/pugh/miklos/pascal/gcc-2.95.2/libiberty/../include argv.c -o pic/argv.o gcc -c -DHAVE_CONFIG_H -O2 -I. -I/home/pugh/miklos/pascal/gcc-2.95.2/libiberty/../include argv.c gcc: argv.c: No such file or directory gcc: No input files *** Error code 1 (bu21) *** Error code 1 (bu21)
Looks like a patch problem.
But wait, perhaps this /usr/lib32/mips3/crt1.o is in fact not a static version, and you'll have to install a static version in /usr/lib32/mips3/nonshared in the first place (since GCC doesn't seem to install it, maybe it's part of the OS -- I don't know what IRIX installation is like, but on Linux I'd say you'd have to install packages for static runtime library support or similar).
You are right. The static libs are not present on my system. Too bad...
miklos
Miklos Cserzo wrote:
On Sat, 8 Dec 2001, Frank Heckenbach wrote:
What exactly happens with the native tools?
Here is the log (the whole lot):
make CFLAGS=-O2 if [ x"no" = xyes ] && [ ! -d pic ]; then \ mkdir pic; \ else true; fi touch stamp-picdir test x"no" != xyes || \ gcc -c -DHAVE_CONFIG_H -O2 -I. -I/home/pugh/miklos/pascal/gcc-2.95.2/libiberty/../include argv.c -o pic/argv.o gcc -c -DHAVE_CONFIG_H -O2 -I. -I/home/pugh/miklos/pascal/gcc-2.95.2/libiberty/../include argv.c gcc: argv.c: No such file or directory gcc: No input files *** Error code 1 (bu21) *** Error code 1 (bu21)
Looks like a patch problem.
Why? These files are not part of GPC at all, and not affected by GPC's back-end patch (only files under gcc/ are).
Hmm, do you use non-GNU *make*? That's another thing. ISTR it says in the GCC documentation that this generally won't work, and I don't think they'll ever "fix" it. (Variations between different `make's are simply too big, as I've noticed myself, so it's not practical to support more than one "dialect" in a complicated project. `VPATH' is one essential feature present in GNU and some, but not all other `make's, and this seems the relevant one here.)
Frank
On Sun, 9 Dec 2001, Frank Heckenbach wrote:
Why? These files are not part of GPC at all, and not affected by GPC's back-end patch (only files under gcc/ are).
Hmm, do you use non-GNU *make*? That's another thing. ISTR it says in the GCC documentation that this generally won't work, and I don't think they'll ever "fix" it. (Variations between different `make's are simply too big, as I've noticed myself, so it's not practical to support more than one "dialect" in a complicated project. `VPATH' is one essential feature present in GNU and some, but not all other `make's, and this seems the relevant one here.)
You are right again. That was a native 'make' thing. However, the built is OK but the installation fails as follows with the gmake:
make install /bin/sh /home/pugh/miklos/pascal/gcc-2.95.2/mkinstalldirs /var/tmp/gpc /var/tmp/gpc make: file `Makefile' line 1649: Must be a separator (: or ::) for rules (bu39) make: file `Makefile' line 1649: Syntax error *** Error code 1 (bu21) unset echo>
Yours,
miklos
Miklos Cserzo wrote:
You are right again. That was a native 'make' thing. However, the built is OK but the installation fails as follows with the gmake:
make install /bin/sh /home/pugh/miklos/pascal/gcc-2.95.2/mkinstalldirs /var/tmp/gpc /var/tmp/gpc make: file `Makefile' line 1649: Must be a separator (: or ::) for rules (bu39) make: file `Makefile' line 1649: Syntax error *** Error code 1 (bu21) unset echo>
The line breaks are quite messed up, or was it really like this?
Anyway, it looks like you called the native make again (`make install' instead of `gmake install'). The message `Must be a separator' does not appear to be from GNU make.
Frank
On Mon, 10 Dec 2001, Frank Heckenbach wrote:
Anyway, it looks like you called the native make again (`make install' instead of `gmake install'). The message `Must be a separator' does not appear to be from GNU make.
Sorry, sorry and sorry again. I am a bit unfocused in these days..
miklos
-
Frank Heckenbach -
Miklos Cserzo