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
Related
I ran into a rather bizarre issue while building a dynamic library. Here are details with a small example:
A simple file called static.h whose contents are:
#pragma once
#include <string>
std::string static_speak();
static.cpp looks like this:
#include "static.h"
std::string static_speak() {
return "I am static";
}
one can build a static library with these two files (using cmake) as:
add_library(static
static.cpp
)
Now, consider another file called shared.cpp whose contents are:
#include "static.h"
std::string dynamic_speak() {
return static_speak() + " I am dynamic";
}
One can try to build a dynamic library (again using cmake) as:
add_library(shared SHARED
shared.cpp
)
target_link_libraries(shared PRIVATE
static
)
When one tries to build the above, one will run into the following error:
[4/4] Linking CXX shared library libshared.so
FAILED: libshared.so
: && /opt/vatic/bin/clang++ -fPIC -g -shared -Wl,-soname,libshared.so -o libshared.so CMakeFiles/shared.dir/shared.cpp.o libstatic.a && :
/usr/bin/ld: libstatic.a(static.cpp.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Nonrepresentable section on output
clang-10: error: linker command failed with exit code 1 (use -v to see invocation)
ninja: build stopped: subcommand failed.
This makes sense. We didn't compile static with POSITION_INDEPENDENT_CODE. That is easily fixable via:
add_library(static
static.cpp
)
set_target_properties(static
PROPERTIES
POSITION_INDEPENDENT_CODE ON
)
Everything works perfectly now when one compiles shared library.
Now here is the problem. Let's say I didn't enable POSITION_INDEPENDENT_CODE but instead disabled exceptions (!) in my code as:
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fno-exceptions")
Now when I try to compile shared, everything still works!!
How are exceptions and fPIC related to each other?
Here is a repo to reproduce the issue:
https://github.com/skgbanga/shared
How are exceptions and fPIC related to each other?
They aren't (mostly).
What happens is that compiling with -fno-exceptions changes the relocations (certain exception-related data is no longer referenced), and because of that, there is no relocation which causes the error at link time.
You can confirm this by building with and without -fno-exceptions, and comparing output from objdump -dr CMakeFiles/static.dir/static.cpp.o.
P.S. I could not reproduce your problem using g++ (Debian 9.3.0-8), because it defaults to building with -fPIE, and both links succeed.
And if I add -fno-pie, then both links fail the same way.
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 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.
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.
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