ld unpredictable lookup failure building shared library

Ian Lance Taylor iant@google.com
Sat Apr 21 19:01:00 GMT 2012

"James K. Lowden" <jklowden@schemamania.org> writes:

> Good to know, thanks.  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

> For a .so, perhaps that's what "DYNAMIC" means?  


>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.  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.
So something is wrong.  The most likely problem is that the symbol is
not defined in any object file included in the link.  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.


More information about the Binutils mailing list