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
Attachment:
signature.asc
Description: This is a digitally signed message part.
-- fedora-test-list mailing list fedora-test-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list
