This is the mail archive of the crossgcc@sourceware.cygnus.com mailing list for the crossgcc project.
See the CrossGCC FAQ for lots more infromation.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
> I am trying to build a cross-gcc/newlib environment for an > arm-unknown-coff target on a linux host. > > I am following the Cross-GCC FAQ using GCC 2.95.2, binutils > 2.9.1, and newlib 1.8.2. First, I run the one-tree-1.6.sh > script. Then I edit newlib-1.8.2/newlib/configure.host and > comment out both ARM_RDP_MONITOR and ARM_RDI_MONITOR since > I am not using those tools. Next, I run the build script: > build-cross.sh arm-unknown-coff. Finally, I su-root and > install. > > The target is an ARM4 architecture StrongARM core inside an > Intel/LevelOne IXP1200 network processor. > > I am at the point where I can compile and run a program > which prints "Hello, World" over the serial line using the > UART. I now want to get the libraries setup so that I > can use "printf". > > I know I need to create a new (or modify an old) crt0.S file. > I also know I need to hook my UART routines into read() and > write(). > > Here are some observations which may or may not help isolate > the remaining things I need to do: > > 1. The first few lines of output from the build-cross.sh > script are troubling: > ./build-cross.sh: started Mon May 8 15:38:54 EDT 2000 > ./build-cross.sh: configure for arm-unknown-coff. > Configuring for a i686-pc-linux-gnu host. > *** This configuration is not supported in the following > subdirectories: > target-libgloss > (Any other directories should still work fine.) > Created "Makefile" in /home/CrossGCC/b-arm-unknown-coff > > Is this a problem? Do I need to modify the configuration > files so that libgloss can be made? > This shouldn't be a problem. I don't think you need anything from libgloss. > > 2. When I compile an empty main() program, I get a couple of > errors: > $ cat main.c > int main(void) { return 0; } > $ arm-unknown-coff-gcc -I. -mcpu=strongarm110 -mapcs-32 > -mno-sched-prolog -fvolatile -fno-builtin -Wall > -Wstrict-prototypes -O2 -c main.c -o main.o > $ arm-unknown-coff-ld -o main.coff main.o -X -N > -Ttext 00001000 -lc > arm-unknown-coff-ld: warning: cannot find entry symbol > _start; defaulting to 00001000 > main.o(.text+0xc):fake: undefined reference to `__gccmain' > > Where should __gccmain be resolved? In crt0.o or a library? > What type of object is it? (Or, is there a way to prevent > it from being generated if that is more appropriate?) > It's normally better to use gcc to do your linking (at least until you really need to control the linker in a much finer manner). In this case, you need to add gcc's runtime support library (libgcc); but gcc will add that automatically. Try: arm-unknown-coff-gcc -o main.coff main.o adding -v to the above will force gcc to show you the command line that it passes to the linker. > > 3. When I compile the traditional "Hello, World" program, I get > the above errors plus a slew of undefined references: > $ cat hw.c > #include <stdio.h> > int main(void) { printf("Hello, World\n"); return 0; } > > $ arm-unknown-coff-gcc -I. -mcpu=strongarm110 -mapcs-32 > -mno-sched-prolog -fvolatile -fno-builtin -Wall > -Wstrict-prototypes -O2 -c hw.c -o hw.o > $ arm-unknown-coff-ld -o hw2.coff hw2.o -X -N > -Ttext 00001000 -lc > arm-unknown-coff-ld: warning: cannot find entry symbol > _start; defaulting to 00001000 > /usr/xcc/arm/arm-unknown-coff/lib/libc.a(vfprintf.o): > In function `vfprintf_r': /home/CrossGCC/b-arm-unknown-coff/ > arm-unknown-coff/newlib/libc/stdio/../../../../../src/newlib/ > libc/stdio/vfprintf.c:565: undefined reference to `__ltdf2' > /home/CrossGCC/b-arm-unknown-coff/arm-unknown-coff/newlib/ > libc/stdio/../../../../../src/newlib/libc/stdio/vfprintf.c:721: > undefined reference to `__umodsi3' > /home/CrossGCC/b-arm-unknown-coff/arm-unknown-coff/newlib/ > libc/stdio/../../../../../src/newlib/libc/stdio/vfprintf.c:722: > undefined reference to `__udivsi3' > [...remainder deleted...] > > This looks like it is related the common difficulty addressed in > the CrossGCC FAQ: http://www.objsw.com/CrossGCC/FAQ-5.html#ss5.4 > While I can stub out system library calls, I'll still need to > provide real versions of __ltdf2, __umodsi3, __udivsi3, ... > I assume these routines are either in newlib (which may have been > built incorrectly), or in libgloss (which didn't get built). Same answer as above. R. ------ Want more information? See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/ Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |