This is the mail archive of the crossgcc@sources.redhat.com mailing list for the crossgcc project.
See the CrossGCC FAQ for lots more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Mark Palmerino wrote: > > Hi Kai, > > Continuing from earlier, I am working on your suggestion to see if I can > find what is different between the windows version and the unix version. > > The next step I thought worth taking is to bring over the libc.a, libbcc.a > and libgcc.a from the windows side and use them as arguments to the linker. > I did that and put them in the directory that the hello.c file is in and > here is the ld command which I used: > > m68k-coff-ld -v -o $FN.cof \ > -L. \ > $FN.o -lc -lbcc -lgcc -T rm_rom.ld -M > $FN.map The GNU ld does things in the order you command it to do... Here is my guess about what it would do: 1. link your $FN.o 2. scan the libs 3. look at the linker script etc. You can easily see what it REALLY does by substituting the '-v' with '-verbose'. > Where $FN is 'hello'. When I execute that command, I get: > > ./libc.a(exit.o)(.text+0x52):exit.c: undefined reference to `_exit' > ./libc.a(sbrkr.o)(.text+0x12):sbrkr.c: undefined reference to `sbrk' > ./libc.a(makebuf.o)(.text+0xdc):makebuf.c: undefined reference to `isatty' > ./libc.a(readr.o)(.text+0x1a):readr.c: undefined reference to `read' > ./libc.a(lseekr.o)(.text+0x1a):lseekr.c: undefined reference to `lseek' > ./libc.a(writer.o)(.text+0x1a):writer.c: undefined reference to `write' > ./libc.a(closer.o)(.text+0x12):closer.c: undefined reference to `close' > ./libc.a(fstatr.o)(.text+0x16):fstatr.c: undefined reference to `fstat' > > This seems odd since all of these are declared in the libbcc.a library in > the directory. Here is the output from ar: > > m68k-coff-ar tv libbcc.a > rw-rw-r-- 500/500 4440 Aug 13 22:23 1999 fstat.o > rw-rw-r-- 500/500 2212 Aug 13 22:23 1999 getpid.o > rw-rw-r-- 500/500 2234 Aug 13 22:23 1999 isatty.o > rw-rw-r-- 500/500 2322 Aug 13 22:23 1999 kill.o This doesn't tell anything, but the 'm68k-coff-nm libgcc.a | grep exit' for the first undefined would have told something... Of couse it would be unexpected if the 'libc.a' and 'libbcc.a' weren't in sync what becomes to the symbol names... > I don't quite know where to go from here. Do you have any suggestions? Perhaps the 'libbcc.a' wasn't indexed by 'm68k-coff-ranlib', you could try that or put a 'libbcc.a' instead of '-lbcc' into the command line... But checking with 'm68k-coff-nm' the symbol name in 'libc.a', being there as undefined, 'U', and in 'libbcc.a', being there as defined, 'T' is the first thing to do, like here for '_exit' : E:\usr\local\m68k-coff\lib>..\bin\nm libc.a | grep exit U _exit atexit.o: 00000000 T atexit exit.o: U _exit 00000000 T exit E:\usr\local\m68k-coff\lib>..\bin\nm libbcc.a | grep exit U _exit 00000000 T _exit The names must be same. Here we can see that probably the 'exit.o' in 'libc.a' has the function 'exit()' which calls the function '_exit()' and this function is somewhere in 'libbcc.a'. Using '...| more' and browsing/searching for '_exit' would tell in which compiled object the function is... In 'libbcc.a' there is another function calling the '_exit()' and in 'libc.a' too... Cheers, Kai ------ 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] |