This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: ld unpredictable lookup failure building shared library
"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