[Linux-ia64] "unsupported reloc" error with ld

[Linux-ia64] "unsupported reloc" error with ld

[gjertsen]

Can a compiler person out there provide some insight
on the following error I get with some C++ code when
doing a final bind with ld:

fs/fs.o(.IA_64.unwind+0x98b8): unsupported reloc
(... a bunch of these ...)

I am trying out the new toolchain from cygnus, 1024 snapshot,
with the old glibc v2.1.3 (and the 2 patches for ABI and shared libs).
This is an improvement from before when I was also getting additional
"Dwarf Error" messages with the current turbolinux toolchain:

--------------------------------------------------------------------------------------------------
ld: Dwarf Error: Could not find abbrev number 100.
(... a bunch more similar to this ...)
fs/fs.o(.IA_64.unwind+0x98d0): unsupported reloc
(... a bunch more similar to this ...)
--------------------------------------------------------------------------------------------------

Based on scaning the IA64 mail lists I saw two notes
that discussed similar looking problems that referred
to C++ EH and the use of inconsistant libraries and toolchain:

[Linux-ia64] Bad unwind record ...   Mon, 24 Jul 2000
[Linux-ia64] ld failure  26 Apr 2000

Thanks,

--Rob

Re: [Linux-ia64] "unsupported reloc" error with ld

[Jim Wilson]

>Can a compiler person out there provide some insight
>on the following error I get with some C++ code when
>doing a final bind with ld:

>fs/fs.o(.IA_64.unwind+0x98b8): unsupported reloc
>(... a bunch of these ...)

The fs.o object file contains a relocation that GNU ld does not support
in the context where it appeared.  It is not possible to say anything more
about this problem without further info.  If you debug the linker, you
can find out the number of the relocation and the context where it is being
used.  Or if you provide object files to me, I can do this.

Are you using gcc?  If you are using some other compiler, then the other
compiler could be emitting relocs that GNU ld doesn't support yet.

The dwarf error messages can be ignored.  The linker is trying to pretty
print error messages by using the debug info to determine the function name
and line number where the problem occured.  This pretty printing code is
failing because the debug info hasn't been relocated yet, and hence isn't
valid as is.  Someday this will be fixed by extending this code to relocate
the debug info before trying to use it if possible.

Neither old message seems relevant to me.

Jim