ld unpredictable lookup failure building shared library

James K. Lowden jklowden@schemamania.org
Sun Apr 22 02:17:00 GMT 2012


On Sat, 21 Apr 2012 11:29:37 -0700
Ian Lance Taylor <iant@google.com> wrote:
> "James K. Lowden" <jklowden@schemamania.org> writes:
> 
> > How to verify a .o file was compiled with -fPIC?
> 
> There is no simply way to tell, unfortunately.  It's a matter of the
> relocations.  Some relocations can occur in a -fPIC object, some can
> not.

Thank you.  At least I understand the limit of what can be shown here.  

> From your original message, the linker said this:
> 
> > $ /usr/pkg/bin/gnu-ld @linker.options
> > /usr/pkg/bin/gnu-ld: /usr/pkgsrc/wip/clang/work/llvm/Release/lib/libLLVMCodeGen.a
> > (ShrinkWrapping.o): relocation R_X86_64_PC32 against undefined
> > symbol `_ZNSs4_Rep10_M_disposeERKSaIcE'
> > can not be used when making a shared object; recompile with -fPIC
> 
> I assume that this is the GNU linker and that you introduced the line
> breaks.  

Yes. 

> The linker is quite correct: a R_X86_64_PC32 relocation
> against an undefined symbol can not be used in a shared object.  Such
> a relocation should never be generated by the compiler when using
> -fPIC. 

I appreciate your help, Ian.  I hope to find a way to get you the
information you need to isolate the cause of the problem. 

This is not the only R_X86_64_PC32 in the file; it's just the only one
the linker doesn't like:

$ readelf -a ../../lib/CodeGen/Release/ShrinkWrapping.o \
	| sed -Ene '/R_X86_64_PC32/p' | wc -l
     762

Regarding this particular symbol, though, objdump finds it and readelf
does not:

$ objdump -x ../../lib/CodeGen/Release/ShrinkWrapping.o | grep
_ZNSs4_Rep10_M_disposeERKSaIcE 
0000000000000000         *UND* 0000000000000000
	_ZNSs4_Rep10_M_disposeERKSaIcE 
000000000000004e R_X86_64_PC32
	_ZNSs4_Rep10_M_disposeERKSaIcE+0xfffffffffffffffc

$ readelf -rw  ../../lib/CodeGen/Release/ShrinkWrapping.o \
	| grep -c '_ZNSs4_Rep10_M_disposeERKSaIcE' 
0

I suspect that's evidence of an error on the part of the compiler.  

I found a message from you from a year ago regarding -fPIC asking about
PLT and GOT:

$ readelf -r ../../lib/CodeGen/Release/ShrinkWrapping.o \
	| awk '/PLT|GOT/ {print $3}' | sort | uniq -c 
104 R_X86_64_GOTPCREL
 259 R_X86_64_PLT32

> So something is wrong.  The most likely problem is that the
> symbol is not defined in any object file included in the link.  

That statement confuses me.  Either the compiler emitted incorrect code
("should never be generated") or the code is OK by the linker line is
wrong ("not defined in any object file included in the link").  Unless  
the compiler was supposed to generate code but mistakenly opted to punt
over to the linker by emitting R_X86_64_PC32 instead?  Perhaps because
it's a template we're talking about?  

We know where the symbol is defined i.e., where the object code is that
we want the linker to find

$ nm /usr/lib/libstdc++.so | grep _ZNSs4_Rep10_M_disposeERKSaIcE
000000000006f830 W _ZNSs4_Rep10_M_disposeERKSaIcE

and we know where it's referenced, because that's in the linker message.
What do you mean by "not defined in any object file"?  Does the library
not count as "an object file"?  Does the symbol in ShrinkWrapping.o not
count as a "definition"?   (I am not in the least trying to be
flippant.  I hope that's clear.)  

> I know that you showed that another instance of libstdc++.so has a
> weak definition for the symbol, but you should see whether the symbol
> is defined in the specific link that is causing this error.

I feel like I'm half a step behind you.  To me, libstdc++.so doesn't
have an "instance".  It's a file on the path and the linker uses it.
What is this instance of which you speak?  

I also don't understand "symbol is defined in the specific link".  I
guess you mean "among the things mentioned on the linker command line"
but I'm afraid I've used all the tools I know.  I scanned the tree
of .o files in the project directory for any mention of that symbol.  I
found three, and they all look like the one in ShrinkWrapping.o (as far
as nm shows).  

Thanks again for your time and interest.  I'm crossing my fingers,
hoping there's enough floundering around and guesses here to help you
lead me in the right direction.  

--jkl



More information about the Binutils mailing list