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
not.

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

No.


>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.

Ian



More information about the Binutils mailing list