undefined reference when mixing a.out and ELF object files ?

Vincent Rivière vincent.riviere@freesbee.fr
Fri May 2 08:37:00 GMT 2008


Nick Clifton wrote:
> It is probably an unsupported mix.  There are quite a few cases already 
> where the linker cannot handle converting being object file formats at 
> the same time as performing a final link.  The safest method is to 
> convert b.o to ELF first and then link it with a.o second.

Hello Nick, thank you for your quick answer.

I used the debugger yesterday, trying to see where something goes wrong, 
but I didn't find anything useful. I imagine somewhere in the linker 
code, there is a lookup for the symbol, and it is probably not found 
because it has not been loaded...
I noticed bfd_perform_relocation() returns bfd_reloc_undefined in the 
bad case, but it is probably the result of an earlier problem.

 > The only real bug in this case is that the linker should be detecting 
 > an attempt to link-and-convert for a combination that it does not
 > support and then issuing an appropriate error message.

I'm ready to help for providing such a patch, unfortunately I don't have 
the required knowledge :-(


Some background information: I'm working on the unsupported 
m68k-atari-mint target. It uses a.out-zero-big as object file format, 
and a special flavor of a.out as executable format. The a.out format 
becomes a problem, because it is being fewer and fewer supported and 
tested by the binutils and gcc, and it becomes very hard to find help 
for fixing a.out related bugs (especially gcc). So I would like to 
switch to ELF like everyone (and enjoy ELF benefits, too).

I hoped that configuring gas for generating ELF object files would be 
enough. That way, the new programs will use ELF object files, while 
keeping the standard a.out-like executable format, and while being 
compatible with the old a.out libraries. Unfortunately, it doesn't work 
because of the "bug" described here :-(

-- 
Vincent Rivière



More information about the Binutils mailing list