"b.zaar" <billy.zaar@xxxxxxxxx> writes: > Hi, I'm using a cross compiler for i386-elf to develop a boot loader. I'm > using the gcc tools under cygwin if that might make a difference. The > problem is an undefined reference to an existing symbol. The code is > compiled with nasm and then linked with gnu ld. I'm finding ld wont link > with more than 5 global symbols defined in the nasm elf object file. This is > the output from the link command. > > $ i386-elf-ld.exe -y print -y printhex -Map loader.map -T > ../../src/boot/loader > .ld start.o pmi.o cpuid.o main.o int.o -o loader > start.o: definition of printhex > start.o: definition of print > pmi.o: reference to print > pmi.o: reference to printhex > pmi.o: In function `initpmi': > /usr/src/venom-os/src/boot/pmi.s:(.text16+0x6): undefined reference to > `print' > pmi.o: In function `pmdie.skip': > /usr/src/venom-os/src/boot/pmi.s:(.text16+0x64): undefined reference to > `print' > /usr/src/venom-os/src/boot/pmi.s:(.text16+0x6): undefined reference to > `print' > pmi.o: In function `pmdie.skip': > /usr/src/venom-os/src/boot/pmi.s:(.text16+0x64): undefined reference to > `print' I don't know what is happening here. But one thing to check is to use readelf -s to look at the actual symbol tables. The messages from the linker tend to drop leading underscores, so it is possible that some symbols have a leading underscore and some do not. Also use readelf to confirm that the symbols in start.o are STB_GLOBAL rather than STB_LOCAL. Other than that I really can't think of what could be going wrong here. If you can't figure it out, I recommend opening a linker bug report at http://sourceware.org/bugzilla/ ; attach the actual .o files and linker script that you are using. Ian
