I am attempting to build clang 3.0.99, as currently in pkgsrc-wip.
The build is interrupted by complaints about -fPIC, which *is* used.
The above discussion indicates a problem with "visibility".
Still plugging away at this. "make clean; make" brought me again
to a linker error in ShrinkWrapping.o. The symbol it wants in defined
in the GNU libstdc++ library. nm(1) reports it's defined as a "weak
symbol that has not been specifically tagged as a weak object symbol".
The error reported by the linker may be misleading.
I would appreciate any advice. I have time to track it down; perhaps
we can solve this now for others in the future.
First, the error message:
relocation R_X86_64_PC32 against
can not be used when making a shared object; recompile with -fPIC
That symbol is referenced in two places (so far), and defined in
$ find . -name \*.o | xargs nm -o | grep _ZNSs4_Rep10_M_disposeERKSaIcE
and the reason it's not defined isn't hard to discover (wrapped for
your viewing pleasure)
$ c++filt _ZNSs4_Rep10_M_disposeERKSaIcE
nm(1) reports it's defined as a "weak symbol that has not been
specifically tagged as a weak object symbol":
$ find /usr/lib -name \*.a | xargs nm -o \
> grep _ZNSs4_Rep10_M_disposeERKSaIcE \
> grep -v i386
That object file, string-inst.o, was compiled with -fPIC
$ ar x /usr/lib/libstdc++.a string-inst.o && file string-inst.o
string-inst.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV),
$ nm string-inst.o | grep _ZNSs4_Rep10_M_disposeERKSaIcE
0000000000000000 W _ZNSs4_Rep10_M_disposeERKSaIcE
and the other file that uses that symbol, GCOVProfiling.o, is
successfully incorporated into a library, libLLVMInstrumentation.a:
$ find ../.. -name \*.a
> while read F; do \
ar t $F | grep GCOVProfiling $F && echo $F; \
ar: ../../test/Archive/MacOSX.a: Malformed archive
Binary file ../../Release/lib/libLLVMInstrumentation.a matches
$ ar t ../../Release/lib/libLLVMInstrumentation.a
I set VERBOSE = 1 in Makefile.config to grab the command line.
Rerunning the command with clang++ (1.0) produced exactly the same
error, as though the GNU linker is still invoked. That's not too
surprising because afaik there is no clang linker for x86_64.
Many thanks for your kind attention.