On Friday 30 May 2008, gjohnson5 wrote:
I've been reading that this is a common problem gcc-4.3
/usr/bin/ld: .libs/bytebuffer.o: relocation R_X86_64_32 against `a local
symbol' can not be used when making a shared object; recompile with -fPIC
.libs/bytebuffer.o: could not read symbols: Bad value
collect2: ld returned 1 exit status
make[4]: *** [libakode.la] Error 1
make[4]: Leaving directory
`/usr/local/rpmbuild/BUILD/akode-2.0.2/akode/lib' make[3]: *** [all] Error
2
make[3]: Leaving directory
`/usr/local/rpmbuild/BUILD/akode-2.0.2/akode/lib' make[2]: ***
[all-recursive] Error 1
make[2]: Leaving directory `/usr/local/rpmbuild/BUILD/akode-2.0.2/akode'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/usr/local/rpmbuild/BUILD/akode-2.0.2'
make: *** [all] Error 2
error: Bad exit status from /var/tmp/rpm-tmp.35312 (%build)
I'm just wondering if there are some flags I can pass the compiler instead
of having to build the whole SRPM with -fPIC? It's definitly an easy fix,
but compiling executables fPIC doesn't seem optimal performance wise
-fPIC is needed on quite a few arches. if the shared object is to big you
either need to use -fPIC or change the code to make it smaller.
There are quite a few packages that use -fPIC for s390 s390x sparc and sparc64
Dennis