I'm Trying to Link a static Library to a shared library , I'm Getting the Following error
/usr/bin/ld: ../../../libraries/log4cplus/liblog4cplus.a(fileappender.o): relocation R_X86_64_32S against `a local symbol' can not be used when making a shared object; recompile with -fPIC
../../../libraries/log4cplus/liblog4cplus.a: could not read symbols: Bad value
collect2: ld returned 1 exit status
But this worked on a 32bit machine without any such error. I tried adding The -fPIC flags manually to the Makefile that too didn't solve the problem
I tried the -whole-archive flag as suggested here but with no success.
/usr/bin/ld: ../../../libraries/log4cplus/liblog4cplus.a(appenderattachableimpl.o): relocation R_X86_64_32S against `vtable for log4cplus::spi::AppenderAttachable' can not be used when making a shared object; recompile with -fPIC
../../../libraries/log4cplus/liblog4cplus.a(appenderattachableimpl.o): could not read symbols: Bad value
collect2: ld returned 1 exit status
Creation of liblog4cplus.a:
unzip log4cplus-1.1.0.zip
./configure --enable-static=yes --enable-threads=yes
vi Makefile and added -fPIC to CXXFLAGS and CFLAGS
make
Then for Compiling my shared library:
g++ -frtti -w -c -fPIC -I"Include_Directory" myfile.cpp
g++ -shared -fPIC -frtti -I"Include_Directory" -o mysofile.so myfile.o -Wl,--whole-archive "../../../libraries/log4cplus/liblog4cplus.a" -Wl,--no-whole-archive -ldl
Assuming you are generating a shared library, most probably what happens is that the variant of liblog4cplus.a you are using wasn't compiled with -fPIC. In linux, you can confirm this by extracting the object files from the static library and checking their relocations:
ar -x liblog4cplus.a
readelf --relocs fileappender.o | egrep '(GOT|PLT|JU?MP_SLOT)'
If the output is empty, then the static library is not position-independent and cannot be used to generate a shared object.
Since the static library contains object code which was already compiled, providing the -fPIC flag won't help.
You need to get ahold of a version of liblog4cplus.a compiled with -fPIC and use that one instead.
Add -fPIC at the end of CMAKE_CXX_FLAGS and CMAKE_C_FLAG
Example:
set( CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall --std=c++11 -O3 -fPIC" )
set( CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -Wall -O3 -fPIC" )
This solved my issue.
Relocation R_X86_64_PC32 against undefined symbol , usually happens when LDFLAGS are set with hardening and CFLAGS not .
Maybe just user error:
If you are using -specs=/usr/lib/rpm/redhat/redhat-hardened-ld at link time,
you also need to use -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 at compile time, and as you are compiling and linking at the same time, you need either both, or drop the -specs=/usr/lib/rpm/redhat/redhat-hardened-ld .
Common fixes :
https://bugzilla.redhat.com/show_bug.cgi?id=1304277#c3
https://github.com/rpmfusion/lxdream/blob/master/lxdream-0.9.1-implicit.patch
I've got a similar error when installing FCL that needs CCD lib(libccd) like this:
/usr/bin/ld: /usr/local/lib/libccd.a(ccd.o): relocation R_X86_64_32S against `a local symbol' can not be used when making a shared object; recompile with -fPIC
I find that there is two different files named "libccd.a" :
/usr/local/lib/libccd.a
/usr/local/lib/x86_64-linux-gnu/libccd.a
I solved the problem by removing the first file.
I also had similar problems when trying to link static compiled fontconfig and expat into a linux shared object:
/opt/rh/devtoolset-7/root/usr/libexec/gcc/x86_64-redhat-linux/7/ld: /3rdparty/fontconfig/lib/linux-x86_64/libfontconfig.a(fccfg.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
/opt/rh/devtoolset-7/root/usr/libexec/gcc/x86_64-redhat-linux/7/ld: /3rdparty/expat/lib/linux-x86_64/libexpat.a(xmlparse.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
[...]
This contrary to the fact that I was already passing -fPIC flags though CFLAGS variable, and other compilers/linkers variants (clang/lld) were perfectly working with the same build configuration. It ended up that these dependencies control position-independent code settings through despicable autoconf scripts and need --with-pic switch during build configuration on linux gcc/ld combination, and its lack probably overrides same the setting in CFLAGS. Pass the switch to configure script and the dependencies will be correctly compiled with -fPIC.
Related
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'm trying to compile a shared library (windows equivalent of a .dll) and it gives me the following error:
usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/4.8/crtbeginT.o: relocation R_X86_64_32 against `__TMC_END__' can not be used when making a shared object; recompile with -fPIC
/usr/lib/gcc/x86_64-linux-gnu/4.8/crtbeginT.o: error adding symbols: Bad value
I've never seen this error before. Ever. I'm using codeblocks and g++ 4.8.1. What causes this error?
I'm compiling my own code using:
g++ -shared obj/Debug/src/Bitmap.o obj/Debug/src/Exports.o obj/Debug/src/Hooks.o obj/Debug/src/main.o obj/Debug/src/Platform.o obj/Debug/src/SharedMemory.o obj/Debug/src/SmartJNI.o -o bin/Debug/libGLXColour.so -libGL.so -pthread
/usr/bin/ld: obj/Debug/src/Bitmap.o
I am having an issue compiling my program here are my gcc options used
g++ -shared -fPIC -fvisibility -L/usr/lib/x86_64-linux-gnu/ -lboost_serialization-mt -lboost_thread-mt -lboost_date_time-mt -lboost_iostreams-mt -lboost_program_options-mt -lboost_filesystem-mt -lboost_system-mt
output
relocation R_X86_64_32S against `vtable for boost::detail::sp_counted_base' can not be used when making a shared object; recompile with -fPIC
could not read symbols: Bad value
Does anyone know why this is happening ? thanks
Install the boost library using apt-get install libboost
If you have any issues installing libboost, refer this link in order to get them clarified.
After doing this, you can recompile boost with -fPIC flag in order to resolve the issue. I think the warning itself is helpful to identify your issue.
when compiling shared library which links boost and python libraries I receive error:
/usr/bin/ld: libboost_python.a(from_python.o): relocation R_X86_64_32
against `.rodata.str1.8' can not be used when making a shared object;
recompile with -fPIC libboost_python.a: could not read symbols: Bad
value
I've used verbose mode to look at compiler definitions:
/usr/bin/c++ -fPIC -g -shared -Wl,-soname,libCore.so -o
.../libCore.so Core.cpp.o -lpython2.7 -Wl,-Bstatic -lboost_python
-Wl,-Bdynamic
That's it! I have to remove -Wl, -Bstatic from definitions but how to do that? I'm using cmake build system and here is a part of code which generates that shared library:
set(Core_SRC
Core.cpp
)
add_definitions(-g -fPIC)
add_library(Core SHARED ${Core_SRC})
target_link_libraries(Core
${PYTHON_LIBRARIES}
${Boost_LIBRARIES}
)
The problem is you're trying to build a shared library with libboost_python which appears to have been built in such a way that it can't be linked into a shared library.
There's 3 ways round that.
Don't make your library shared
Build a shared version of the boost_python library
eave the references to boost_python unresolved
So I've been coding something on 32-bit and yesterday I needed to build a dll and I had a couple of problems with that. Anyway I solved them here.
Unfortunately even if I thought that everything was working after all I found that wasn't the case when I moved my program and makefile on other computer what runs on 64bit, as you can guess what happened...
So my problem is related to relocation because of 64bit
/usr/bin/ld: MyClass.o: relocation R_X86_64_32S against `.rodata' can not be used when making a shared object; recompile with -fPIC
MyClass.o: could not read symbols: Bad value
and here is my makefile
MyProgram: main.o chkopts
-${CLINKER} -o $# $< ${MYLIB} ${PETSC_MAT_LIB}
${RM} main.o
export LD_LIBRARY_PATH=${LIBADD}:$LD_LIBRARY_PATH
LibMyProgram.so: MyClass.o chkopts
-${CLINKER} -shared -Wl,-soname,${SONAME} -o ${VERS} *.o ${PETSC_MAT_LIB}
mv ${VERS} ${LIBADD}
ln -sf ${LIBADD}${VERS} ${LIBADD}${SOWOV}
ln -sf ${LIBADD}${VERS} ${LIBADD}${SONAME}
I've tried to add -fPIC in CFLAGS, CPPFLAGS and even LDFLAGS. I've also tried add -fPIC before and after -shared flag.
-${CLINKER} -shared -fPIC -Wl,-soname,${SONAME} -o ${VERS} *.o ${PETSC_MAT_LIB}
But I'll just get a same error as previously.
If I use CFLAGS = -fPIC I'll get a bit same kind of error which is:
.../petsc/petsc-3.2-p6/arch-linux2-cxx-debug/lib/libpetsc.a(err.o): relocation R_X86_64_32 against `ompi_mpi_comm_self' can not be used when making a shared object; recompile with -fPIC.
I've read about all the topics what are even remotely similar with my problem but I've been unable to figure this out.
I encountered the same problem when I try to create a shared library which need to link a static library.
I solved the problem by adding -fPIC to CXXFLAGS to compile .o files which are archived in the static library.
The solution was to compile everything with -fPIC, and link shared objects with -shared.
Add -fPIC to CFLAGS or CXXFLAGS for make-based projects.
Trying to compile xmlrpc-c-1.06.41 in CentOS 6.5, I have encountered same linking problem, which was solved by the following:
In ./src/cpp, I have modified Makefile: line 142 to
CXXFLAGS = $(CXXFLAGS_COMMON) $(CFLAGS_PERSONAL) $(CADD) -shared -fPIC
More info regarding the flags can be found link
If this problem still exist after adding "-fPIC",try clean all the .o files,and run again
I also meet this problem.
As I try using #Mare and #user2391685 said, it can work well :
Using -fPIC when comepile to .o file :
For example:
gcc -Wall -fPIC -c hello.c -I./ -I/usr/lib/jvm/java/include/ -I/usr/lib/jvm/java/include/linux/
Then you can build a .so file :
gcc -Wall -rdynamic -shared -o libhello.so hello.o Main.h -I/usr/lib/jvm/java/include/ -I/usr/lib/jvm/java/include/linux/
this work as a charm. for who not know yet this easy used
an open file called Makefile.am or Makefile. Just up to your config.
look the code at this _a_CXXFLAGS = or just CXXFLAGS =
add after that files -shared -fPIC
this example
before
crypto_libmubdi_crypto_a_CXXFLAGS = $(AM_CXXFLAGS) $(PIC_FLAGS) $(CXXFLAGS_COMMON) $(CFLAGS_PERSONAL) $(CADD)
after
crypto_libmubdi_crypto_a_CXXFLAGS = $(AM_CXXFLAGS) $(PIC_FLAGS) $(CXXFLAGS_COMMON) $(CFLAGS_PERSONAL) $(CADD) -shared -fPIC
these bugs cause we not put shared for the files or need -fPIC strings/tags.
Note: I experience on to build my blockchain. and this cause added this crypto/sph_sha2big.c
In the command line:
cmake -DCMAKE_EXE_LINKER_FLAGS="-no-pie"
Or in the CMakeList.txt:
set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -no-pie")
Relocation R_X86_64_PC32 against undefined symbol , usually happens when LDFLAGS are set with hardening and CFLAGS not .
An usually happens when configure.ac override all system flags with CFLAGS="something" you need change it to CFLAGS+="something"
https://github.com/rpmfusion/lxdream/blob/master/lxdream-0.9.1-implicit.patch
https://bugzilla.redhat.com/show_bug.cgi?id=1304277#c3