Re: LD undefined reference to existing symbol

[Ian Lance Taylor <iant at google dot com>]

"b.zaar" <billy.zaar@gmail.com> 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