Gert Doering wrote:
In the meantime, I tried something else - gcc-3.2.3 with gpc-20040516, again on AIX 5.1 and additionally on AIX 5.2 (in case AIX 5.1 is broken).
Incidentally I also have to build GPC on AIX 5 at the moment (powerpc-ibm-aix5.1.0.0).
Although gcc-3.2.1 was already installed on the system, building with it didn't seem to work (unrecognizable insn). So I did this ...
export CC=cc ../gcc-3.3.3/configure --prefix=$HOME/usr --enable-languages=pascal gmake bootstrap
The effect is quite different here. It builds all of xgpc and the libgpc.a just fine, but then crashes in trying to build "binobj".
(BTW, I wouldn't call an error message a crash. To me a crash is a segfault or something like this.)
The error is this:
gmake[2]: Entering directory `/s1/gpc-build/gcc/p/utils' ../.././xgpc -B../.././ -I../rts --automake --executable-file-name -W -Wall -Wmissing-prototypes -Wmissing-declarations -g -O2 --executable-path=. --unit-path=/s1/gcc-3.2.3/gcc/p/rts --unit-path=/s1/gcc-3.2.3/gcc/p/units `cat needed-options` "/s1/gcc-3.2.3/gcc/p/utils/binobj.pas" collect2: library libgpc not found
... and got this as well.
If I change the -B invocation to use an absolute path,
Or do this (which I'm adding in GPC):
--- p/Make-lang.in.orig Mon May 31 02:18:22 2004 +++ p/Make-lang.in Sun Jun 27 20:01:26 2004 @@ -195,7 +195,7 @@ # Flags to pass when building the utilities. (PC is the GPC for the host!) UTILS_FLAGS_TO_PASS=\ SHELL="$(SHELL)" \ - PC="`if [ x"$(GPC_HOST)" = x"$(target)" ]; then echo $(GPC_FOR_TARGET)' '; else echo $(CC) | $(GCC2GPC); fi | $(ADD_RTS_PARENT_DIR)` -I../rts" \ + PC="`if [ x"$(GPC_HOST)" = x"$(target)" ]; then echo $(GPC_FOR_TARGET)' '; else echo $(CC) | $(GCC2GPC); fi | $(ADD_RTS_PARENT_DIR)` -I../rts -L../.." \ CFLAGS="$(CFLAGS)" \ PFLAGS="$(PFLAGS)" \ exeext="$(exeext)" \
the library is found, but the (AIX) ld doesn't really like the result either:
../.././xgpc -B/s1/gpc-build/gcc/ -I../rts --automake --executable-file-name -W -Wall -Wmissing-prototypes -Wmissing-declarations -g -O2 --executable-path=. --unit-path=/s1/gcc-3.2.3/gcc/p/rts --unit-path=/s1/gcc-3.2.3/gcc/p/units `cat needed-options` "/s1/gcc-3.2.3/gcc/p/utils/binobj.pas" ld: 0711-317 ERROR: Undefined symbol: Tempdirectory.1 ld: 0711-317 ERROR: Undefined symbol: Tempstr.4 ld: 0711-317 ERROR: Undefined symbol: Buffer.8 ld: 0711-317 ERROR: Undefined symbol: Zero.3 ld: 0711-317 ERROR: Undefined symbol: Epoch.6 ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. collect2: ld returned 8 exit status
Then I get that as well.
Since I had the nagging suspicion that there might be something in the pascal libraries that the system ld doesn't understand, I tried installing the GNU binutils, ./configure'd again, and rebuilt.
Built bombed in libgcc (gcc created stuff that gas didn't like).
Yes, the GCC install instructions say this won't work.
/gnulocal/src/gcc-3.2.3/gcc/libgpc.a(filename.o)(.tc+0x4):filename.pas: undefined reference to `Tempdirectory.1' /gnulocal/src/gcc-3.2.3/gcc/libgpc.a(filename.o)(.tc+0x4):filename.pas: undefined reference to `Tempstr.4' /gnulocal/src/gcc-3.2.3/gcc/libgpc.a(filename.o)(.tc+0x4):filename.pas: undefined reference to `Buffer.8' /gnulocal/src/gcc-3.2.3/gcc/libgpc.a(time.o)(.tc+0x4):time.pas: undefined reference to `Zero.3' /gnulocal/src/gcc-3.2.3/gcc/libgpc.a(time.o)(.tc+0x4):time.pas: undefined reference to `Epoch.6' collect2: ld returned 1 exit status
--> so it seems that actually the library itself has unresolved symbols, and not the "binobj.pas" program it tries to link.
Yes. I think I know what's causing this (probably a GPC bug). I'm trying to solve it, will report soon (I hope) ...
Any further ideas how to tackle this? The whole symbol format confuses me - being a C programmer, I'm used to errors about "_crypt" not found, but not without a "_" and neither with trailing numbers...
BTW, I only seem to remember a `_' prefix on DJGPP and such systems (for compatibility with some ancient Dos assemblers, but that's another story) -- unless the programmer puts one there intentionally. The numbers are appended by GCC or the linker for local symbols to avoid collisions when the same name is used in different scopes. But probably that's all irrelevant to the problem.
Frank