Compiling module on linux - c++

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

Related

g++ compile error: `.rodata' can not be used when making a shared object; recompile with -fPIC

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.

final link failed: Nonrepresentable section on output collect2: error: ld returned 1 exit status

I am using these library in my project
Crow Framework
SQLPP11
SQLPP-Connector-MySQL
Howard Hinnant's Date
json11
and compiling my project using
g++ -std=c++1y -I ../../date main.cpp -lpthread -lsqlpp-mysql -lmysqlclient -lboost_system -ljson11
And everyday was running completely fine till yesterday. But now i am getting
this error,
┌─[shravan40#Debian] - [~/Work/algorithm] - [Fri Nov 18, 18:33]
└─[$] <git:(riskProfiling*)> g++ -std=c++1y -I ../../date main.cpp -lpthread -lsqlpp-mysql -lmysqlclient -lboost_system -ljson11
/usr/bin/ld: //usr/local/lib/libsqlpp-mysql.a(connection.cpp.o): relocation R_X86_64_32 against symbol `__pthread_key_create##GLIBC_2.2.5' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: //usr/local/lib/libsqlpp-mysql.a(prepared_statement.cpp.o): relocation R_X86_64_32 against symbol `__pthread_key_create##GLIBC_2.2.5' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: //usr/local/lib/libsqlpp-mysql.a(char_result.cpp.o): relocation R_X86_64_32 against `.rodata' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: //usr/local/lib/libsqlpp-mysql.a(bind_result.cpp.o): relocation R_X86_64_32 against symbol `__pthread_key_create##GLIBC_2.2.5' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: //usr/local/lib/libsqlpp-mysql.a(connection_handle.cpp.o): relocation R_X86_64_32 against symbol `__pthread_key_create##GLIBC_2.2.5' 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
┌─[shravan40#Debian] - [~/Work/algorithm] - [Fri Nov 18, 18:53]
└─[$] <git:(riskProfiling*)>
Finally, i have figured out the solution.
It was the problem with g++ version. Recent versions g++-5 and g++-6 have such problems, But when i get back to old g++ version 4.9.2 everything is running smooth.
I had a similar issue after upgrading from 16.04 LTS to 18.04 LTS; but for me it was easily solved by running "make clean" and rebuilding the project. This might not work for everyone, but it is so simple that it seems likely that it is worth a try as a first resort for anyone who has this problem.
I had the same problem after upgrading from 16.04 LTS to 18.04 LTS with gtest/gmock library. Solution is you need recompile your libraries which you use in project with currently compiler.

error in compilation with ld : __stack_chk_guard##GLIBC_2.17

I am compiling some files on the odroidC2 board (armv8-64bit) running Ubuntu 16.04.1, and I got the following error:
odroid#odroid64:~/flext-master/tutorial/simple1$ g++ -fPIC -L/usr/lib -pthread -shared -Wl,-S -L/usr/local/src/pd/bin -L/usr/local/lib -o pd-linux/release-single/simple1.pd_linux pd-linux/release-single/main.opp -lflext-pd_s
/usr/bin/ld: /usr/local/lib/libflext-pd_s.a(libflext_pd_s_la-flxlet.o): relocation R_AARCH64_ADR_PREL_PG_HI21 against external symbol `__stack_chk_guard##GLIBC_2.17' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: /usr/local/lib/libflext-pd_s.a(libflext_pd_s_la-flxlet.o)(.text+0x344): unresolvable R_AARCH64_ADR_PREL_PG_HI21 relocation against symbol `__stack_chk_guard##GLIBC_2.17'
/usr/bin/ld: final link failed: Bad value
collect2: error: ld returned 1 exit status
As you can see the -fPIC option is present. So I don't understand why the compiler suggest to "recompile with -fPIC". Any Idea?
The problem is not in the pd-linux/release-single/main.opp (BTW, maybe .cpp?) that you're compiling with -fPIC, but in the libflext-pd_s.a archive that contains an object libflext_pd_s_la-flxlet.o which is not compiled with -fPIC, so you need to recompile flext library properly.

Undefined reference to 'dlsym' and 'dlopen'

I am compiling using arm-linux-gnueabi-g++ version 4.7.3.
I have the arm-linux-gnueabi libraries installed at location:
/usr/arm-linux-gnueabi/lib, it contains libdl.a, libdl.so, libdl.so.2,
and libdl-2.19.so.
libdl.so links to libdl.so.2 which links to libdl-2.19.so.
I am trying to link against the dl library (see command string below), but I always get the undefined reference errors.
arm-linux-gnueabi-g++ -I. -I../ -I../Comms/Linux -Wall -DLINUX -fpic -o ../../work/MyProgram main.o
-L../../work -L/usr/arm-linux-gnueabi/lib -lComms -lConsole -lUtilities -ldl
../../work/libUtilities.so: undefined reference to `dlsym'
../../work/libUtilities.so: undefined reference to `dlopen'
collect2: error: ld returned 1 exit status
If I compile using g++ 4.8.2 using the following commend then my program compiles, links, and executes fine.
g++ -I. -I../ -I../Comms/Linux -Wall -DLINUX -fpic -o ../../work/MyProgram main.o
-L../../work -lComms -lConsole -lUtilities -ldl
Obviously it can't find the libdl.so library; I thought that by adding the path to the location of the appropriate library by using the -L flag would fix the problem, but it didn't.
What am I missing with the ARM compiler command?
Well, I found the answer, I needed -Wl,--no-as-needed flag before the -ldl. I had run across this flag before I asked the question, but apparently mistyped it because it hadn't worked for me.
I don't understand why the flag is needed, but the code does finish linking now.
A SO user here says that it has to do with recent (2013 as of the user's post) versions of gcc linking to --as-needed.

"relocation R_X86_64_32S against " linking Error

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.