Recompiling with -fPIC
I have MPICH 3.0.4 installed on my machine (Ubuntu 12.04). I am trying to install a library called Qthreads which I have worked with and successfully installed before (except with the MPICH2 package installed). The configuration works fine: ./configure —prefix=/usr/local/qthreads —enable-multinode —with-multinode-runtime=mpi —with-portals4=/usr/local/portals4 —with-hwloc=/usr/local/hwloc :
. . . System Characteristics: Target Style: unix Multi-node: yes, mpi Topology API: hwloc Qtimer type: clock_gettime Aligned_t size: 8 (aligned on 8 byte boundaries) Default Stack size: 4kB Safety/Debugging: Sanity assert()s: no Check alignment: no Profiling: none Debugging Output: no Guard Pages: no Speed: Scheduler: sherwood (multiworker shepherds) Sinc Style: donecount Barrier Style: feb Dictionary Style: simple Lazy Thread IDs: yes Pools/caches: memory, spawns RCRTool: no Increments/CAS/FEBs: Compiler Builtin (both), lock-based hash . . . CCLD libqthread.la /usr/bin/ld: /usr/local/lib/libmpich.a(barrier.o): relocation R_X86_64_32 against `MPIR_ThreadInfo' can not be used when making a shared object; recompile with -fPIC /usr/local/lib/libmpich.a: could not read symbols: Bad value collect2: ld returned 1 exit status make[2]: *** [libqthread.la] Error 1 make[2]: Leaving directory `/home/alex/Downloads/qthread-1.9/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/alex/Downloads/qthread-1.9/src' make: *** [all-recursive] Error 1 I have looked around and it seems the obvious (and possible only) solution is to do what the compiler says: recompile with -fPIC . However, I’m hesitant to go through and edit any Makefiles for Qthreads, as they are long and complicated. Is there an easy way to recompile with -fPIC ? Please advise. I appreciate any input.
How to recompile libperl.a object files with -fPIC flag?
This question arose when trying to fix some installation problems with QtCore4 . At some point make tried to run the following command:
/usr/bin/c++ -fPIC -fwrapv -fno-strict-aliasing -pipe -fstack-protector-strong \ -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O3 -DNDEBUG \ -shared -Wl,-soname,QtCore4.so -o ../../blib/arch/auto/QtCore4/QtCore4.so \ CMakeFiles/perlqtcore4.dir/binding.cpp.o \ CMakeFiles/perlqtcore4.dir/handlers.cpp.o \ CMakeFiles/perlqtcore4.dir/marshall_types.cpp.o \ CMakeFiles/perlqtcore4.dir/util.cpp.o \ CMakeFiles/perlqtcore4.dir/QtCore4.c.o \ -lQtCore -lQtGui -lQtNetwork \ /home/hakon/perlbrew/perls/perl-5.24.1/lib/5.24.1/x86_64-linux/CORE/libperl.a \ ../../smokeqt/qtgui/libsmokeqtgui.so.3.0.0 \ ../../smokeqt/qtnetwork/libsmokeqtnetwork.so.3.0.0 \ -lpthread -lnsl -ldl -lm -lcrypt -lutil -lc -lQtGui -lQtNetwork \ ../../smokeqt/qtcore/libsmokeqtcore.so.3.0.0 -lQtCore \ ../../smokegen/bin/libsmokebase.so.3.0.0 \ -Wl,-rpath,/home/hakon/Qt4-0.99.0/smokeqt/qtgui:/home/hakon/Qt4-0.99.0/smokeqt/qtnetwork:/home/hakon/Qt4-0.99.0/smokeqt/qtcore:/home/hakon/Qt4-0.99.0/smokegen/bin: /usr/bin/ld: /home/hakon/perlbrew/perls/perl-5.24.1/lib/5.24.1/x86_64-linux/CORE/libperl.a(toke.o): relocation R_X86_64_PC32 against symbol `PL_curcop' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: final link failed: Bad value collect2: error: ld returned 1 exit status - How can I recompile the object files in libperl.a with -fPIC ?
- Could this recompilation cause other problems not related to QtCore4 (since it is likely that libperl.a will be used (linked with) by other applications/programs not related to QtCore4 )?
I am using Ubuntu 16.10 and perl version 5.24.1.
How to recompile with -fPIC
I was trying to reinstall my ffmpeg, following this guide, on my ARM Ubuntu machine. Unfortunately, when I compile a program which uses this lib I get the following failure:
/usr/bin/ld: /usr/local/lib/libavcodec.a(amrnbdec.o): relocation R_ARM_MOVW_ABS_NC against `a local symbol' can not be used when making a shared object; recompile with -fPIC /usr/local/lib/libavcodec.a: could not read symbols: Bad value collect2: ld returned 1 exit status Now I would like to recompile it with -fPIC like the compiler is suggesting but I have no idea how. Any help is appreciated.
9 Answers 9
Briefly, the error means that you can’t use a static library to be linked w/ a dynamic one. The correct way is to have a libavcodec compiled into a .so instead of .a , so the other .so library you are trying to build will link well.
The shortest way to do so is to add —enable-shared at ./configure options. Or even you may try to disable shared (or static) libraries at all. you choose what is suitable for you!
Thanks for this! I also want to add that I also had to do make distclean when re-running make to get rid of some files that had already been compiled in a static manner.
you can try globally adding the flag using: export CXXFLAGS=»$CXXFLAGS -fPIC»
This fixed a node package installer (for node-swipl) that was using node-gyp and had been producing the same error. Thanks 🙂
I had this problem when building FFMPEG static libraries (e.g. libavcodec.a) for Android x86_64 target platform (using Android NDK clang). When statically linking with my library the problem occured although all FFMPEG C -> object files (*.o) were compiled with -fPIC compile option:
x86_64/libavcodec.a(h264_qpel_10bit.o): requires dynamic R_X86_64_PC32 reloc against 'ff_pw_1023' which may overflow at runtime; recompile with -fPIC The problem occured only for libavcodec.a and libswscale.a.
Source of this problem is that FFMPEG has assembler optimizations for x86* platforms e.g. the reported problem cause is in libavcodec/h264_qpel_10bit.asm -> h264_qpel_10bit.o.
When producing X86-64 bit static library (e.g. libavcodec.a) it looks like assembler files (e.g. libavcodec/h264_qpel_10bit.asm) uses some x86 (32bit) assembler commands which are incompatible when statically linking with x86-64 bit target library since they don’t support required relocation type.
Possible solutions:
- compile all ffmpeg files with no assembler optimizations (for ffmpeg this is configure option: —disable-asm)
- produce dynamic libraries (e.g. libavcodec.so) and link them in your final library dynamically
I chose 1) and it solved the problem.
Recompiling with -fPIC
After all of the discussion, I did a completely fresh install of MPICH 3.0.4, with —enable-shared being the only configure option given. For some reason it compiled and built successfully, despite not doing so before. After this was accomplished, Qthreads was configured and built successfully without requiring any extra options.
Solution 2
The ultimate answer is going to depend on the makefiles in question but using make CFLAGS=-fPIC might work as might MYCFLAGS or any of a number of other such variables. You’ll have to look and see what Qthreads is using to create that archive.
Solution 3
It’s also possible that this is a symptom and not the problem. Take a look at this answer and see if it helps (how to recompile with -fPIC). As of MPICH 3.0.4, the default is to build with shared libraries instead of static, so you may need to make sure that they’re consistent.
Alex Brooks
I received my Bachelor of Arts in Mathematics and Computer Science from Monmouth College. I am now currently a Ph.D. student in Computer Science at the University of Illinois at Urbana-Champaign.
Comments
I have MPICH 3.0.4 installed on my machine (Ubuntu 12.04). I am trying to install a library called Qthreads which I have worked with and successfully installed before (except with the MPICH2 package installed). The configuration works fine: ./configure —prefix=/usr/local/qthreads —enable-multinode —with-multinode-runtime=mpi —with-portals4=/usr/local/portals4 —with-hwloc=/usr/local/hwloc :
. . . System Characteristics: Target Style: unix Multi-node: yes, mpi Topology API: hwloc Qtimer type: clock_gettime Aligned_t size: 8 (aligned on 8 byte boundaries) Default Stack size: 4kB Safety/Debugging: Sanity assert()s: no Check alignment: no Profiling: none Debugging Output: no Guard Pages: no Speed: Scheduler: sherwood (multiworker shepherds) Sinc Style: donecount Barrier Style: feb Dictionary Style: simple Lazy Thread IDs: yes Pools/caches: memory, spawns RCRTool: no Increments/CAS/FEBs: Compiler Builtin (both), lock-based hash . . . CCLD libqthread.la /usr/bin/ld: /usr/local/lib/libmpich.a(barrier.o): relocation R_X86_64_32 against `MPIR_ThreadInfo' can not be used when making a shared object; recompile with -fPIC /usr/local/lib/libmpich.a: could not read symbols: Bad value collect2: ld returned 1 exit status make[2]: *** [libqthread.la] Error 1 make[2]: Leaving directory `/home/alex/Downloads/qthread-1.9/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/alex/Downloads/qthread-1.9/src' make: *** [all-recursive] Error 1 I have looked around and it seems the obvious (and possible only) solution is to do what the compiler says: recompile with -fPIC . However, I’m hesitant to go through and edit any Makefiles for Qthreads, as they are long and complicated. Is there an easy way to recompile with -fPIC ? Please advise. I appreciate any input.
Thank you for the reference Wesley. I checked out the solution and tried a few different configurations without any luck. I tried recompiling MPICH with —enable-shared only to be met with a similar error ( relocation R_X86_64_32 against ‘.rodata’ can not be used when making a shared object;. ). Then I tried recompiling Qthreads with —enable-shared and —disable-static also with no luck (same error as in OP). Do you have any suggestions as to how I should recompile either MPICH or Qthreads?
Did you try compiling MPICH with —enable-static since that’s the non-default case? It probably won’t make a difference, but that’s the only combination you have left?
I was able to successfully compile and build MPICH with enable-static . However I am still unable to make Qthreads, even after trying every combination of —enable-shared and —enable-static ; I continue to receive the same error, regardless of which I use.
Ah, well in that case I’m less sure about what your problem might be. Did you try the suggestion in the other answer ( make CFLAGS=-fPIC )?
Yup I have added the -fPIC option to every *FLAGS variable, all with no results. Although, it seems I should be adding the option for compiling MPICH rather than Qthreads, since the error strictly regards libmpich.a . I will see what I can do about attempting the option during compiling MPICH
I checked out configure.ac for MPICH 3.0.4, and I found something interesting: LT_INIT([disable-shared]) . Afterwards, a check is done, disabling rpath if shared libraries are disabled. Is this a bug? Since you mentioned that —enable-shared is the default for MPICH 3.0.4
Ah, apparently I was wrong about shared libraries being the default in 3.0.4. That happened just after it was released so they will be the default for 3.1.