This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]