I have a project (not mine) which I want to build. It has c++ and Python modules, which has to bind. When I launch cmake, I get this error:
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib/libantlr.a(BitSet.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib/libantlr.a: error adding symbols: Bad value
collect2: error: ld returned 1 exit status
make[2]: *** [python/CModule.so] Error 1
make[1]: *** [pyBinding/CMakeFiles/CMODULE.dir/all] Error 2
make: *** [all] Error 2
I install antlr library with apt-get, and as I understand, I should recompile this library, but I have no idea in which part of source code of antlr library I should put -fPIC, or is there another way?
In Ubuntu 14.10 I have package libantlr-dev, which contains libantlr.a as well as libantlr-pic.a. I believe you have to use latter one, it is compiled with PIC
Related
I've connected two libraryes.
a) HotStuff https://github.com/hot-stuff/libhotstuff
b) Bls (with relic) https://github.com/Chia-Network/bls-signatures
I had to add a lot of bls flags into the hotstuff cmake:
(On root dir level)
https://gist.github.com/Raycoms/29e58b80fb493d89d1ea4bfe6f953984
(In examples folder)
https://gist.github.com/Raycoms/8e757d0ab0fd61a006db629dbc35e6fc
However, when building this, this results in the following exception:
/usr/bin/ld: _deps/relic-build/lib/librelic_s.a(relic_core.c.o): relocation R_X86_64_TPOFF32 against symbol `core_ctx' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: bls/src/libblstmp.a(elements.cpp.o): warning: relocation against `_ZTVSt9basic_iosIcSt11char_traitsIcEE##GLIBCXX_3.4' in read-only section `.text._ZN3bls4Util6HexStrB5cxx11ERKSt6vectorIhSaIhEE[_ZN3bls4Util6HexStrB5cxx11ERKSt6vectorIhSaIhEE]'
/usr/bin/ld: bls/src/libblstmp.a(elements.cpp.o): relocation R_X86_64_PC32 against symbol `_ZN3bls4Util19secureAllocCallbackE' 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
make[2]: *** [CMakeFiles/hotstuff_shared.dir/build.make:90: libhotstuff.so] Error 1
make[1]: *** [CMakeFiles/Makefile2:350: CMakeFiles/hotstuff_shared.dir/all] Error 2
make: *** [Makefile:133: all] Error 2
Weirdly, compiling and running it in CLion works just fine, but doing it in the commandline results in the above exception which leaves me confused.
Quick update. It works in CLion because executing "make" in the examples folder works well enough to build the app and app-client starters.
However, the overall build doesn't work.
You need to tell cmake that the target producing the librelic_s.a static lib should use position independent code by setting the POSITION_INDEPENDENT_CODE target property:
add_library(relic_s STATIC ...)
set_target_properties(relic_s PRIVATE POSITION_INDEPENDENT_CODE True)
Not sure this can be done without modifying the cmake file of relic...
So, what i'm actually trying to is to build a shared object, that contains a python-includable-module, generated by pybind11. I got it as far as to have no syntax-errors in CLion, but when i try to compile it, it gives the following error:
/usr/bin/ld: //usr/local/lib/libraw.a(utils_libraw.o): relocation R_X86_64_PC32 against symbol `stderr##GLIBC_2.2.5' 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
CMakeFiles/cr3_to_python.dir/build.make:98: recipe for target 'cr3_to_python.cpython-36m-x86_64-linux-gnu.so' failed
make[3]: *** [cr3_to_python.cpython-36m-x86_64-linux-gnu.so] Error 1
CMakeFiles/Makefile2:77: recipe for target 'CMakeFiles/cr3_to_python.dir/all' failed
make[2]: *** [CMakeFiles/cr3_to_python.dir/all] Error 2
CMakeFiles/Makefile2:84: recipe for target 'CMakeFiles/cr3_to_python.dir/rule' failed
make[1]: *** [CMakeFiles/cr3_to_python.dir/rule] Error 2
Makefile:118: recipe for target 'cr3_to_python' failed
make: *** [cr3_to_python] Error 2
When compiling with c++ i get something very similar:
$ c++ -O3 -Wall -shared -std=c++11 -fPIC -I/usr/include/python3.6m/ -I/usr/local/include/opencv4/ $(python3 -m pybind11 --includes) main.cpp -o cr3_to_python$(python3-config --extension-suffix) -lraw
/usr/bin/ld: //usr/local/lib/libraw.a(utils_libraw.o): relocation R_X86_64_PC32 against symbol `stderr##GLIBC_2.2.5' 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
What annoys me the most is the actual error:
/usr/bin/ld: //usr/local/lib/libraw.a(utils_libraw.o): relocation R_X86_64_PC32 against symbol `stderr##GLIBC_2.2.5' can not be used when making a shared object; recompile with -fPIC
Because i didn't include anything related to stderr (from my point of view) in the code.
main.cpp
CMakeLists.txt
When compiling a shared library on Linux and Macos (and probably other Unixy OSes) all code used in the library needs to be compiled in "position independent mode", this is because the compiler doesn't know where an executable will load your code so has to generate code which can be run from any address.
To generate PIC code you need to pass the -fPIC flag to GCC.
Note that all the code you want to compile into your shared library needs to be compiled in PIC mode, this includes code in static libraries. In your case you need to recompile libraw.a with -fPIC enabled.
Position independent code might be slightly slower but the difference is small so you can probably just compile all your code with -fPIC even if its being used directly in an executable. Apple recommends that all code including executables is position independent. See How much overhead can the -fPIC flag add? for more details about performance.
I'm writting a extension for pyton3.6. My develop machine run gcc7.3, and production environment os is centos6. I use the following link option to static link glibc to avoid upgrade glibc2.12 to glibc2.14+.
-Wl,-Bdynamic -lpython3.6m -Wl,-Bstatic -lboost_python36
But get error:
[ 50%] Linking CXX shared module helloext.so
/usr/bin/x86_64-linux-gnu-ld: cannot find -lgcc_s
/usr/bin/x86_64-linux-gnu-ld: cannot find -lgcc_s
collect2: error: ld returned 1 exit status
CMakeFiles/helloext.dir/build.make:94: recipe for target 'helloext.so' failed
make[2]: *** [helloext.so] Error 1
CMakeFiles/Makefile2:67: recipe for target 'CMakeFiles/helloext.dir/all' failed
make[1]: *** [CMakeFiles/helloext.dir/all] Error 2
Makefile:83: recipe for target 'all' failed
make: *** [all] Error 2
Anyone known? Thanks.
The reason might be although libgcc is present it may not be in the paths known to ldconfig. Check this by doing
/sbin/ldconfig -p | grep libgcc
Does the output show that there is a link to libgcc corresponds to paths that you have listed above?
A work around for you may be to add the link to the relevant library to your compile command e.g.
... -L /usr/lib/gcc/x86_64-linux-gnu/4.6/
Another may be to create a symbolic link to the library yourself.
ln -s /usr/lib/gcc/x86_64-linux-gnu/4.6/libgcc_s.so /usr/lib/gcc/libgcc_s.so
You have not informed us about Linux you are using. Update 4.6 with the proper number in the command above.
When I build a project with cmake, I got following error. Though I tried to add compiling flag -fPIC by add_definition() in the CMakeLists.txt, this error persists. Can anyone help? I am a new guy to cmake. Any suggestions will be highly appreciated.
/usr/bin/ld: /act/mvapich2-1.9/gcc-4.7.2/lib/libmpich.a(mvapich_malloc.o): relocation R_X86_64_32S against `.bss' can not be used when making a shared object; recompile with -fPIC
/act/mvapich2-1.9/gcc-4.7.2/lib/libmpich.a: could not read symbols: Bad value
collect2: error: ld returned 1 exit status
make[2]: *** [src/libstracker.so] Error 1
make[2]: Leaving directory `/home/xxxx/success/AutomaDeD-master'
make[1]: *** [src/CMakeFiles/stracker.dir/all] Error 2
make[1]: Leaving directory `/home/xxxx/success/AutomaDeD-master'
make: *** [all] Error 2
add_definitions is is intended to add preprocessor definitions, not a flag
-fPIC is present by default in the linker flags for a shared library build with GCC, see Modules/Compiler/GNU.cmake. You can see all flags by running make VERBOSE=1.
As for the error itself, see this answer.
I'm trying to compile some code I found on GitHub https://github.com/tapio/Wendy
I'm just trying to compile the stuff in tests/. I never had any experience with cmake, but they're kinda logical anyway.
I got stuck at the part where cmake does this:
/usr/bin/c++ CMakeFiles/clear.dir/clear.o -o clear -rdynamic -lwendy -lglfw -lGLEW -lglm -lz
and gets this error:
Linking CXX executable clear
/usr/bin/ld: cannot find -lwendy
/usr/bin/ld: cannot find -lglm
collect2: ld returned 1 exit status
make[3]: *** [clear] Error 1
make[2]: *** [CMakeFiles/clear.dir/all] Error 2
make[1]: *** [CMakeFiles/clear.dir/rule] Error 2
make: *** [clear] Error 2
I don't understand how the Wendy and glm folder became a compiler flag. Somebody please explain how this is possible. :(
In tests/CMakeLists.txt the line target_link_libraries(${test} wendy ${WENDY_LIBRARIES}) instructs cmake to link the list of libraries in WENDY_LIBRARIES to the executable.