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
Related
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
I recently upgraded gSOAP from 2.8.7 to 2.8.76. I had to make a few minor code adjustments for the upgrade, but after the upgrade the code won't link on the computer it would before.
I'm trying to use gSOAP to create a shared library on a computer which uses g++ 4.9.2. I've condensed the code down to create a test case that simplifies things a bit to try to identify where the failure is occurring.
gSOAP generates some ebaySoapLib* files when I run:
/usr/local/bin/soapcpp2 -z1 -C -w -x -n -pebaySoapLib -qebaySoapLib -I/usr/local/include/gsoap:/usr/local/share/gsoap:/usr/local/share/gsoap/import ebaySvc.h
The -z1 option is to keep things similar to how they were with gSOAP 2.8.7.
If I run:
g++ -fPIC -c ebaySoapLibClientLib.cpp
g++ -shared -fPIC -o test.so ebaySoapLibClientLib.o
I get the error:
/usr/bin/ld: ebaySoapLibClientLib.o: relocation R_X86_64_PC32 against
undefined symbol `soap_serializeheader' 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
I copied over the exact files to another computer running g++ 6.3.0 (not sure that the compiler version is what is mattering or now), and this compiles and links fine.
The file ebaySoapLibClientLib.cpp contains:
#define SOAP_FMAC3 static
#include "ebaySoapLibC.cpp"
#include "ebaySoapLibClient.cpp"
Now, if I remove the line:
#define SOAP_FMAC3 static
then the code compiles fine on both computers.
I'm at a loss for what I need to do differently to make it link OK with the g++ 4.9.2 computer. I could take out the #define so the functions aren't defined static and get it to work, but the question is WHY as gSOAP is putting it in there for a reason, and it links fine on the g++ 6.3.0 with these functions set to static.
You need to get library that supplies soap_serializeheader to be compile ready for shared library, its not ebaySoaLibClientLib.cpp. Use g++ -v to see what libraries g++ is using. Try using shared library instead of static ones.
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.
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).
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.