FS#40174 - [gcc] libiberty.a should be compiled with PIC support

Attached to Project: Arch Linux
Opened by Anatol Pomozov (anatolik) - Thursday, 01 May 2014, 16:39 GMT
Last edited by Allan McRae (Allan) - Friday, 02 May 2014, 10:59 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Allan McRae (Allan)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

I am trying to compile a library (folly-git from AUR) that uses libiberty from GCC.

As far as I see at http://gcc.gnu.org/onlinedocs/libiberty/Using.html#Using libibery is not supposed to work as *.so, the projects should statically link against libibert.a

So I change folly-git PKGBUILD from --disable-shared to --enable-shared. I want to use liberty.a to link with my libfolly.so. It fails:

libtool: link: g++ -fPIC -DPIC -shared -nostdlib /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/crti.o /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/crtbeginS.o .libs/Bits.o .libs/Conv.o .libs/Demangle.o .libs/CacheLocality.o .libs/dynamic.o .libs/EscapeTables.o .libs/File.o .libs/FileUtil.o .libs/Format.o .libs/FormatTables.o .libs/GroupVarint.o .libs/GroupVarintTables.o .libs/IOBuf.o .libs/IOBufQueue.o .libs/RecordIO.o .libs/AsyncTimeout.o .libs/EventBase.o .libs/EventHandler.o .libs/Request.o .libs/json.o .libs/MemoryIdler.o .libs/Malloc.o .libs/MemoryMapping.o .libs/Random.o .libs/Range.o .libs/SpookyHashV1.o .libs/SpookyHashV2.o .libs/Instantiations.o .libs/String.o .libs/Subprocess.o .libs/ThreadCachedArena.o .libs/TimeoutQueue.o .libs/Unicode.o .libs/Uri.o .libs/InlineExecutor.o .libs/ManualExecutor.o .libs/ThreadGate.o .libs/FunctionalExcept.o -L/usr/lib64 -lboost_thread -lboost_system -lboost_regex -lpthread -liberty -levent -ldouble-conversion -lgflags -lglog -L/usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0 -L/usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib -L/lib/../lib -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../.. -lstdc++ -lm -lc -lgcc_s /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/crtendS.o /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib/crtn.o -march=x86-64 -mtune=generic -O2 -Wl,-O1 -Wl,--sort-common -Wl,--as-needed -Wl,-z -Wl,relro -Wl,-soname -Wl,libfolly.so.0 -o .libs/libfolly.so.0.0.0
/usr/bin/ld: /usr/lib64/libiberty.a(cp-demangle.o): relocation R_X86_64_32S against `.rodata' can not be used when making a shared object; recompile with -fPIC
/usr/lib64/libiberty.a: error adding symbols: Bad value
collect2: error: ld returned 1 exit status
Makefile:669: recipe for target 'libfolly.la' failed
make[2]: *** [libfolly.la] Error 1
make[2]: *** Waiting for unfinished jobs....



It looks like libibery.a should be compiled with PIC to let it be linked into shared libraries.
This task depends upon

Closed by  Allan McRae (Allan)
Friday, 02 May 2014, 10:59 GMT
Reason for closing:  Implemented
Additional comments about closing:  In SVN trunk
Comment by Allan McRae (Allan) - Friday, 02 May 2014, 10:59 GMT
Fixed in SVN trunk. I expect gcc will need to be built from a new snapshot soon and I think projects that use libiberty should follow upstream recommendations and bundle it in their source, so I will not be rebuilding now.

Loading...