Link error: "relocation R_X86_64_PC32 against symbol `stdout##GLIBC_2.2.5' can not be used when making a shared object; recompile with -fPIC" - c++

I am trying to build a shared library using Cmake. But I facing this error:
/usr/bin/ld: /usr/local/lib/libfftw3.a(assert.o): relocation R_X86_64_PC32 against symbol `stdout##GLIBC_2.2.5' can not be used when making a shared object; recompile with -fPIC
I tried to add -fPIC flag to cmake file in different ways as:
SET(CMAKE_POSITION_INDEPENDENT_CODE ON)
and:
add_compile_options(-fPIC)
But I still get same error again. Can anybody help me?

As shown by #lubgr and confirmed by #Fayyaz in the comments, the specific problem here was due to the library being linked against needing to be recompiled with the -fPIC flag- not the target linking to that library.

Related

Getting error "can not be used when making a shared object; recompile with -fPIC" although fpic is used

I am currently building a shared library (lib1.so) out of a cmake environment.
lib1.so depends on an external static lib libLASlib.a (which I am able to recompile if necessary).
Everything works wonder on windows so far, but it's another story when switching to linux:
/usr/bin/ld: lib/LASlib/libLASlib.a(lasreader.cpp.o): relocation R_X86_64_PC32 against symbol `_ZN9LASreader35read_point_filtered_and_transformedEv' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Bad value
So I tried recompiling the libLASlib with -fPIC -> same error
Due to my environment I could not verify the fpic was effectivelly added to the gcc command line.
Here is what I tried to confirm there was no issue with the fPIC:
readelf --dynamic libLASlib.a | grep lasreader.cpp.o -A2
File: libLASlib.a(lasreader.cpp.o)
There is no dynamic section in this file.
For the record not a single cpp.o was found with a dynamic section
I have tried just to see what it would give if i changed liblas from a static to a shared library -> no error
Any thoughs?
Many thanks!
You need to compile lasreader.cpp with -fPIC. Something like this:
g++ -c -fPIC -o lasreader.cpp.o lasreader.cpp
The fPIC was indeed not applied
Conan doesn't seem to forward the fPIC option
I edited the CMAKELIST and added
set_property(TARGET LASlib PROPERTY POSITION_INDEPENDENT_CODE ON)
And it eventualy passed

c++ Linker error 'relocation R_X86_64_32 against `.rodata.str1.1' Linking CXX shared library libsrt.so

I am getting this error everytime I run make.If I copy libsrt.so from another directory,then it gets compiled. Anyone has idea?
Linking CXX shared library libsrt.so
/usr/bin/ld: /usr/local/ssl/lib/libcrypto.a(aes_misc.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
/usr/local/ssl/lib/libcrypto.a: error adding symbols: Bad value
collect2: error: ld returned 1 exit status
CMakeFiles/srt.dir/build.make:763: recipe for target 'libsrt.so.1.2.0' failed
what the error message is telling you is that the linking of libsrt.so failed because you tried to link libsrt.so with libcrypto.a but libcrypto.a wasn't complied with -fPIC.
-fPIC is a complier flag that changes the code generation to production position indepandent code (PIC) which is required for shared object because the linker doesn't know where the shared object will be loaded.
to fix this issue you can:
recomplie libcrypto.a with -fPIC if you complied it yourself
use the shared object of libcrypto libcrypto.so if you received compiled binairies
in your case libcrypto being part of openssl using libcrypto.so is much better
You need to build a shared version of libcrypto - libcrypto.so. And link against that (the linker does that automatically when .so is present).

Ubuntu 16.04 Eclipse CPP - error adding symbols: Bad value [duplicate]

I am using the command:
g++ --std=c++11 -fPIC -Iincludes parser.cpp lib/main-parser.o lib/lib.a
To compile a C++ program on Debian 9. But I am getting the below error message:
/usr/bin/ld: lib/lib.a(csdocument.o): relocation R_X86_64_32 against '.rodata' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: error: ld returned 1 exit status
I have already seen the thread:
Compilation fails with "relocation R_X86_64_32 against `.rodata.str1.8' can not be used when making a shared object"
However, I have tried adding the -fPIC argument however it strangely gives the same error message, along with "recompile with -fPIC"
Any ideas would be appreciated. I have tried compiling this on my University's RedHat systems and it works fine there. I'm thinking it could be a missing dependency, but I've been unable to find any answers.
Thanks in advance
As it seems gcc is trying to produce a position-independent executable ("shared object" is the hint), tell it not to:
g++ --std=c++11 -no-pie -Iincludes parser.cpp lib/main-parser.o lib/lib.a
It seems that g++ produces position-independent executables by default on your system. Other systems would require -pie to do so. Using -no-pie should create a "regular" (position dependent) executable.
(The error is a result of trying to link an object file that was compiled as non-position-independent into an executable that is supposed to be position-independent).
/usr/bin/ld: lib/lib.a(csdocument.o): relocation R_X86_64_32 against '.rodata' \
can not be used when making a shared object; recompile with -fPIC
This linker error is telling you that the object file csdocument.o in the
static library lib/lib.a is not Position Independent Code and hence
cannot be linked with your PIE program. So you need to recompile the source
files of lib/lib.a with -fPIC, then rebuild the static library, then link
it with your PIE program. If you don't have control of the libary sources
then request a PIC build from its supplier.
(Others have questioned why you should need to build a PIE target at all
since it's not a shared library. In Debian 9, GCC produces PIE executables
by default,
whether programs or shared libraries. The same goes for Ubuntu as of 17.04. )
Adding this worked for me.
g++ --std=c++11 -no-pie
I also added the -fPIC to compile flag.

How can I use static lib in Shared Library project in Eclipse CDT

I have a Shared Library Project which builds only if I add -fPIC to the Compiler command ( this solves the issue ).
When I try to use a static library in this project I get a similar issue but in this situation I cannot fix with -fPIC:
libtest.a(exception.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
Could I get some help please on how I can link this successfully ? I've tried adding -fPIC to the linker option also but I get the same error.
I am using GCC Compiler on Linux.
From the question it appears you are updating the link time to add -fPIC, but you need to recompile libtest.a with -fPIC so that the relocations created in exception.o and the other objects in the library are PIC compatible.

Errors when linking libsodium.a into a Shared Object

I am trying to use the libsodium library in a C++ project and I'm having difficulty with linking the static Libsodium Library into a Shared Object that I've created. This project is being compiled using G++ and is set to use C++11 Standards.
After reading various forum posts about linking a Static Library into a Shared Object, I've tried using the Whole Archive which seems to get me further but still will not link in correctly.
The following is the Command being used to link:
/usr/bin/g++ -shared -fPIC -o ./Debug/libwowcrypt.so #"libwowcrypt.txt" -L. -L../SharedLibraries/Sodium/lib -Wl,--whole-archive -lsodium -Wl,--no-whole-archive
The following error messages are returned from ld:
/usr/bin/ld: ../SharedLibraries/Sodium/lib/libsodium.a(libsodium_la-hmac_hmacsha256.o): relocation R_X86_64_PC32 against symbol `crypto_auth_hmacsha256_init' 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
Can anyone advise on the correct linker flags that are needed to incorporate this static library into my shared object?
I ran into the same problem. Assuming you are on Ubuntu < 15.04 (mine is 14.04 LTS), you need to disable PIE
./configure --disable-pie
and then the usual: make / make install etc.
Now you should be able to link the static libsodium.a to your .so. I got this from a recent discussion on github issue i raised here