Hi all! I'm trying to build a cross compiler from win32-cygwin to arm-elf. I built the gcc cross compiler that works very well... Now, with the same configuration, I'm trying to build gpc compiler. The building process seems good, but if I try to compile a simple pascal code I obtain some errors:
C:\cygwin\home\Mode3\Nuova cartella>arm-elf-gpc -o prova.o prova.pp /home/gba/lib/gcc-lib/arm-elf/3.3.1/libgpc.a(rts.o)(.text+0xed0): In function `realpath': /home/Administrator/sources/gcc/gcc/p/rts/rts.c:1493: undefined reference to `getcwd' /home/gba/lib/gcc-lib/arm-elf/3.3.1/libgpc.a(rts.o)(.text+0x1114): In function `_p_CStringRealPath': /home/Administrator/sources/gcc/gcc/p/rts/rts.c:1583: undefined reference to `getcwd'
This is my configuration script:
$SRCDIR/configure \ --target=arm-elf --prefix=/home/gba \ --enable-interwork --enable-multilib \ --enable-languages="pascal" \ --with-newlib --with-headers=../gcc/newlib/libc/include \ 2>&1 | tee configure_pas.log
I'm using gcc 3.3.1 and gpc-20030830 patched
Suggestions will be very appreciated ^_^
Francesco Lombardi wrote:
Hi all! I'm trying to build a cross compiler from win32-cygwin to arm-elf. I built the gcc cross compiler that works very well... Now, with the same configuration, I'm trying to build gpc compiler. The building process seems good, but if I try to compile a simple pascal code I obtain some errors:
C:\cygwin\home\Mode3\Nuova cartella>arm-elf-gpc -o prova.o prova.pp /home/gba/lib/gcc-lib/arm-elf/3.3.1/libgpc.a(rts.o)(.text+0xed0): In function `realpath': /home/Administrator/sources/gcc/gcc/p/rts/rts.c:1493: undefined reference to `getcwd' /home/gba/lib/gcc-lib/arm-elf/3.3.1/libgpc.a(rts.o)(.text+0x1114): In function `_p_CStringRealPath': /home/Administrator/sources/gcc/gcc/p/rts/rts.c:1583: undefined reference to `getcwd'
GPC runtime library assumes Unix environment. Your option are: 1) Provide stubs for missing Unix functions. 2) Use GPC without runtime (I wrote int the past to the list how to do it). 3) Write mini-runtime which do not need Unix functions
I you manage 2) you can then proceed to 3) picking the functions that you really need from regular GPC runtime. Or you can do 3) deleting references to Unix functions from regular runtime. I suspect that picking parts that you need is easier then deleting but YMMW.
Waldek Hebisch wrote:
Francesco Lombardi wrote:
Hi all! I'm trying to build a cross compiler from win32-cygwin to arm-elf. I built the gcc cross compiler that works very well... Now, with the same configuration, I'm trying to build gpc compiler. The building process seems good, but if I try to compile a simple pascal code I obtain some errors:
C:\cygwin\home\Mode3\Nuova cartella>arm-elf-gpc -o prova.o prova.pp /home/gba/lib/gcc-lib/arm-elf/3.3.1/libgpc.a(rts.o)(.text+0xed0): In function `realpath': /home/Administrator/sources/gcc/gcc/p/rts/rts.c:1493: undefined reference to `getcwd' /home/gba/lib/gcc-lib/arm-elf/3.3.1/libgpc.a(rts.o)(.text+0x1114): In function `_p_CStringRealPath': /home/Administrator/sources/gcc/gcc/p/rts/rts.c:1583: undefined reference to `getcwd'
GPC runtime library assumes Unix environment. Your option are:
- Provide stubs for missing Unix functions.
- Use GPC without runtime (I wrote int the past to the list how to do
it). 3) Write mini-runtime which do not need Unix functions
I you manage 2) you can then proceed to 3) picking the functions that you really need from regular GPC runtime. Or you can do 3) deleting references to Unix functions from regular runtime. I suspect that picking parts that you need is easier then deleting but YMMW.
If getcwd is the only error you get, we can add an autoconf check for it (just as we do for almost all other Unix-specific functions that we use).
For a quick check if it's the only problem, you can try adding
#define getcwd(buf, size) NULL
in p/rts/rts.c (e.g., in line 215). (But if there were other errors that you trimmed in your mail, I might have to see them to tell if it's worth checking for all of those things.)
Frank
If getcwd is the only error you get, we can add an autoconf check for it (just as we do for almost all other Unix-specific functions that we use).
For a quick check if it's the only problem, you can try adding
#define getcwd(buf, size) NULL
in p/rts/rts.c (e.g., in line 215). (But if there were other errors that you trimmed in your mail, I might have to see them to tell if it's worth checking for all of those things.)
Ok, I'll do a try ASAP. Stay tuned! ^_^
Thanks to all!
Frank
-- Frank Heckenbach, frank@g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html GPC download signing key: ACB3 79B2 7EB2 B7A7 EFDE D101 CD02 4C9D 0FE0
E5E8
For a quick check if it's the only problem, you can try adding
#define getcwd(buf, size) NULL
in p/rts/rts.c (e.g., in line 215). (But if there were other errors that you trimmed in your mail, I might have to see them to tell if it's worth checking for all of those things.)
Ok, with this change all works fine. Next step is to compile interworking code. I do:
arm-elf-gpc -mthumb -o prova.o prova.pp
but I get some warnings:
/home/gba/lib/gcc-lib/arm-elf/3.3.1/../../../../arm-elf/bin/ld: Warning: /home/g ba/lib/gcc-lib/arm-elf/3.3.1/libgpc.a(error.o) does not support interworking, wh ereas prova.o does /home/gba/lib/gcc-lib/arm-elf/3.3.1/../../../../arm-elf/bin/ld: Warning: /home/g ba/lib/gcc-lib/arm-elf/3.3.1/libgpc.a(string2.o) does not support interworking, whereas prova.o does ...
...and a lot of similar warnings. In fact, I compiled gpc with --enable-interwork, but seems like this directive was ignored.
Suggestions?
Francesco
Ok, I'll do a try ASAP. Stay tuned! ^_^
Thanks to all!
Frank
-- Frank Heckenbach, frank@g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html GPC download signing key: ACB3 79B2 7EB2 B7A7 EFDE D101 CD02 4C9D 0FE0
E5E8
Francesco Lombardi wrote:
For a quick check if it's the only problem, you can try adding
#define getcwd(buf, size) NULL
in p/rts/rts.c (e.g., in line 215). (But if there were other errors that you trimmed in your mail, I might have to see them to tell if it's worth checking for all of those things.)
Ok, with this change all works fine.
OK, I'll add an autoconf check so this won't be necessary in the future. Is there another function to get the current directory (if there's such a thing -- I'm not familiar with the platform)?
Frank
For a quick check if it's the only problem, you can try adding
#define getcwd(buf, size) NULL
in p/rts/rts.c (e.g., in line 215). (But if there were other errors that you trimmed in your mail, I might have to see them to tell if it's worth checking for all of those things.)
Ok, with this change all works fine.
OK, I'll add an autoconf check so this won't be necessary in the future. Is there another function to get the current directory (if there's such a thing -- I'm not familiar with the platform)?
Well, I'm not so familiar too ^_^... In order to compile gpc, I forced fake directory handling in rts.h (line 77), by commenting "if defined __arm__ || defined __thumb__", and newlib compilation, by #define _NEWLIB_VERSION. In fact I'm try to build a cross compiler for gameboy advance. A big trouble I get is in order to make a libgpc with interworking (arm - thumb) enabled. In theory it seems to be correctly compiled:
arm-elf-gpc -print-multi-lib .; thumb;@mthumb interwork;@mthumb-interwork thumb/interwork;@mthumb@mthumb-interwork
but, in fact, i can't compile with -mthumb:
arm-elf-gpc -mthumb --gpc-main=main --specs=gba.specs -o prova.o prova.pp /home/gba/bin/../lib/gcc-lib/arm-elf/3.3.1/../../../../arm-elf/bin/ld: /home/gba /bin/../lib/gcc-lib/arm-elf/3.3.1/libgpc.a(init.o)(_p_DoInitProc): warning: inte rworking not enabled. /home/gba/bin/../lib/gcc-lib/arm-elf/3.3.1/../../../../arm-elf/bin/ld: first o ccurrence: /cygdrive/c/DOCUME~1/ADMINI~1/IMPOST~1/Temp/ccEDzG78.o: thumb call to arm /cygdrive/c/DOCUME~1/ADMINI~1/IMPOST~1/Temp/ccEDzG78.o(.text+0x1ce): In function `init_pascal_main_program': : internal error: dangerous error ... snip ...
Sorry for my "shaking" english... I hope you can understand what I have said :)
Frank
-- Frank Heckenbach, frank@g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html GPC download signing key: ACB3 79B2 7EB2 B7A7 EFDE D101 CD02 4C9D 0FE0
E5E8
Francesco Lombardi wrote:
Well, I'm not so familiar too ^_^... In order to compile gpc, I forced fake directory handling in rts.h (line 77), by commenting "if defined __arm__ || defined __thumb__", and newlib compilation, by #define _NEWLIB_VERSION. In fact I'm try to build a cross compiler for gameboy advance. A big trouble I get is in order to make a libgpc with interworking (arm - thumb) enabled. In theory it seems to be correctly compiled:
arm-elf-gpc -print-multi-lib .; thumb;@mthumb interwork;@mthumb-interwork thumb/interwork;@mthumb@mthumb-interwork
but, in fact, i can't compile with -mthumb:
arm-elf-gpc -mthumb --gpc-main=main --specs=gba.specs -o prova.o prova.pp /home/gba/bin/../lib/gcc-lib/arm-elf/3.3.1/../../../../arm-elf/bin/ld: /home/gba /bin/../lib/gcc-lib/arm-elf/3.3.1/libgpc.a(init.o)(_p_DoInitProc): warning: inte rworking not enabled.
GPC has no multilib support ATM. So only default version of `libgpc.a' is built. So you should either make interworking the defult at configure time (if possible, I do not know). Alternatively, you can set PFLAGS variable to pass extra flags to gpc during library build (something like `PFLAGS=-mthumb-interwork' ?).
Hope helps
----- Original Message ----- From: "Waldek Hebisch" hebisch@math.uni.wroc.pl To: gpc@gnu.de Sent: Saturday, January 08, 2005 4:01 AM Subject: Re: Gpc and arm-elf cross compiling
Francesco Lombardi wrote:
Well, I'm not so familiar too ^_^... In order to compile gpc, I forced
fake
directory handling in rts.h (line 77), by commenting "if defined __arm__
||
defined __thumb__", and newlib compilation, by #define _NEWLIB_VERSION. In fact I'm try to build a cross compiler for gameboy advance. A big
trouble
I get is in order to make a libgpc with interworking (arm - thumb)
enabled.
In theory it seems to be correctly compiled:
arm-elf-gpc -print-multi-lib .; thumb;@mthumb interwork;@mthumb-interwork thumb/interwork;@mthumb@mthumb-interwork
but, in fact, i can't compile with -mthumb:
arm-elf-gpc -mthumb --gpc-main=main --specs=gba.specs -o prova.o
prova.pp
/home/gba/bin/../lib/gcc-lib/arm-elf/3.3.1/../../../../arm-elf/bin/ld: /home/gba /bin/../lib/gcc-lib/arm-elf/3.3.1/libgpc.a(init.o)(_p_DoInitProc):
warning:
inte rworking not enabled.
GPC has no multilib support ATM. So only default version of `libgpc.a' is built. So you should either make interworking the defult at configure time (if possible, I do not know). Alternatively, you can set PFLAGS variable to pass extra flags to gpc during library build (something like `PFLAGS=-mthumb-interwork' ?).
Hope helps
I tried the second thing (PFLAGS), but I get similar warnings (interworking not enabled). BTW, there is a way to build libgpc only, without recompiling all gpc?
-- Waldek Hebisch hebisch@math.uni.wroc.pl
Francesco Lombardi wrote:
GPC has no multilib support ATM. So only default version of `libgpc.a' is built. So you should either make interworking the defult at configure time (if possible, I do not know). Alternatively, you can set PFLAGS variable to pass extra flags to gpc during library build (something like `PFLAGS=-mthumb-interwork' ?).
Hope helps
I tried the second thing (PFLAGS), but I get similar warnings (interworking not enabled). BTW, there is a way to build libgpc only, without recompiling all gpc?
GCC Makefiles pass around a lot of variables, so running make in a subdirectory is tricky. However, if you remove `.o' and `.gpi' files from 'p/rts' directory, and them run `make', that should force re-build of libgpc (`make' should reasonably fast find out that there is nothing to do in other directories).
Did you check that your `PFLAGS' setting survived to libgpc build (look in the log for commands used to compile `rtsc.pas')? You probably need to set `PFLAGS' in environment like:
export PFLAGS=.... make
or just hand-edit `p/rts/Makefile' (I do not remember how to properly set `PFLAGS', but the purpose of `PFLAGS' is to pass extra options for compiling libgpc).
I tried the second thing (PFLAGS), but I get similar warnings
(interworking
not enabled). BTW, there is a way to build libgpc only, without recompiling all gpc?
GCC Makefiles pass around a lot of variables, so running make in a subdirectory is tricky. However, if you remove `.o' and `.gpi' files from 'p/rts' directory, and them run `make', that should force re-build of libgpc (`make' should reasonably fast find out that there is nothing to do in other directories).
Did you check that your `PFLAGS' setting survived to libgpc build (look in the log for commands used to compile `rtsc.pas')? You probably need to set `PFLAGS' in environment like:
export PFLAGS=....
Yes, I export PFLAGS in this way; the log file says that rtsc.pas is compiled with -mthumb-interwork flag.
Thanks for your help!
Francesco
Yes, I export PFLAGS in this way; the log file says that rtsc.pas is compiled with -mthumb-interwork flag.
Looking at your previous message I see:
arm-elf-gpc -mthumb --gpc-main=main --specs=gba.specs -o prova.o prova.pp /home/gba/bin/../lib/gcc-lib/arm-elf/3.3.1/../../../../arm-elf/bin/ld: /home/gba /bin/../lib/gcc-lib/arm-elf/3.3.1/libgpc.a(init.o)(_p_DoInitProc): warning: inte rworking not enabled.
That error should now vanish (assuming that `init.pas' also is compiled with `-mthumb-interwork' and that `-mthumb-interwork' is the correct flag to enable interworking (you may browse the build log to see what flags `libgcc' is using)). There is one C file in the runtime library (`rts.c'), does it it also use `-mthumb-interwork' flag? If not not this file may be the only remaining problem.
Francesco Lombardi wrote:
For a quick check if it's the only problem, you can try adding
#define getcwd(buf, size) NULL
in p/rts/rts.c (e.g., in line 215). (But if there were other errors that you trimmed in your mail, I might have to see them to tell if it's worth checking for all of those things.)
Ok, with this change all works fine.
OK, I'll add an autoconf check so this won't be necessary in the future. Is there another function to get the current directory (if there's such a thing -- I'm not familiar with the platform)?
Well, I'm not so familiar too ^_^... In order to compile gpc, I forced fake directory handling in rts.h (line 77), by commenting "if defined __arm__ || defined __thumb__", and newlib compilation, by #define _NEWLIB_VERSION.
I'm adding the autoconf check now (so you should be able to build the next GPC release without this change to rts.c). If not available, the RTS will behave as if the function existed and the call failed (for example, if the current directory is not readable). You probably won't care, if you don't use directories anyway.
Frank
-
Francesco Lombardi -
Frank Heckenbach -
Waldek Hebisch