This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: ld unpredictable lookup failure building shared library
On Sun, 22 Apr 2012 12:21:08 -0700
Ian Lance Taylor <iant@google.com> wrote:
> "James K. Lowden" <jklowden@schemamania.org> writes:
> >
> > It is unclear to me why the compiler would sometimes not
> > define a symbol that cannot be drawn from a library.
>
> I would say that the compiler is in
> error here. The compiler is certainly permitted to refer to a symbol
> drawn from a library. But when compiling with -fPIC, any such
> reference must not use a R_X86_64_PC32 relocation (it should use a
> R_X86_64_PLT32 relocation instead). So the error is that compiler
> emitted a PC32 relocation when it should have emitted a PLT32
> relocation.
Excellent, thanks, that's clear. I am now hopeful that gcc 4.7 will
not exhibit the same behavior.
I at last understand the domain from which the term R_X86_64_PC32 is
taken (elf) and found what appears to be the authoritative
documentation:
http://refspecs.linuxbase.org/elf/
http://refspecs.linuxbase.org/elf/x86_64-abi-0.95.pdf (cf. table 4.10)
I remember when "medium model" meant two 64 KB segments, one for code
and one for data. Plus ça change.
> > $ readelf -rW ../../lib/CodeGen/Release/ShrinkWrapping.o \
> > | grep '_ZNSs4_Rep10_M_disposeERKSaIcE'
> > 000000000000004e 0000013300000002
> > R_X86_64_PC32 0000000000000000
> > _ZNSs4_Rep10_M_disposeERKSaIcE
> > + fffffffffffffffc
>
> The 0x4e is the address of the relocation.
> The readelf -r option just dumps the relocation information, and the
> relocation refers to the symbol table. To see the entry in the symbol
> table, you need to use the readelf -s option.
For the record, readelf reports the symbol as zero:
$ readelf -sW ../../lib/CodeGen/Release/ShrinkWrapping.o \
| sed -Ene '/Num:|_ZNSs4_Rep10_M_disposeERKSaIcE/p'
Num: Value Size Type Bind Vis Ndx Name
307: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND
_ZNSs4_Rep10_M_disposeERKSaIcE
which I assume means "undefined" given what else I've learned here.
Thanks again for taking the time to diagnose and explain what the
message meant in terms I can understand. I've been programming a long
time and I've seen compiler bugs before, but always on the input side.
C++ is a big language, and the creative programmer eventually comes up
with a valid construct that doesn't parse. This is the first time I've
seen invalid object code exit a compiler.
Regards,
--jkl