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.
Related
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.
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.
I'm trying to cross-compile a small test opengl/glew program and I get linker errors from undefined references.
$ /usr/bin/i486-mingw32-g++ -I/usr/i486-mingw32/include -L/usr/i486-mingw32/lib/ -lglfw -lglew32 -lopengl32 main.cc
/tmp/cct8OpVh.o:main.cc:(.text+0x50): undefined reference to `glfwInit'
/tmp/cct8OpVh.o:main.cc:(.text+0xa6): undefined reference to `glfwOpenWindowHint'
...
The same code does work when compiling for linux:
$ g++ -I/usr/include -L/usr/lib/ -lglfw -lGLEW -lGL main.cc
One thing that caught my eye is that every exported symbol from cross-compiled libraries has an extra underscore prefix:
$ nm /usr/lib/libglfw.a | grep glfwInit$
00000000 T glfwInit
$ /usr/i486-mingw32/bin/nm /usr/i486-mingw32/lib/libglfw.a | grep glfwInit$
00000000 T _glfwInit
This seems to be a common thing since even libstdc++.a shares this property, but why is my cross-compiler linker then looking for non-underscore symbols?
Running arch with following packages (local means AUR):
community/mingw32-binutils 2.23.1-3
community/mingw32-gcc 4.7.2-1
local/mingw32-glew 1.9.0-1
local/mingw32-glfw 2.7.7-1
community/mingw32-pthreads 2.9.1-1
community/mingw32-runtime 3.20-4
community/mingw32-w32api 3.17-1
EDIT
After playing out with both pkg-config and watching glfw recompile and test itself, I came up with the following magic that seems to work, at least I'm compiling:
/usr/bin/i486-mingw32-g++ -I/usr/i486-mingw32/include -L/usr/i486-mingw32/lib -mwindows main.cc -lglew32 /usr/i486-mingw32/lib/libglfw.a /usr/i486-mingw32/lib/libopengl32.a -static-libgcc
There are few questions though:
What is the difference between linking with -l and without?
Why do I need to use -l with glew and cannot with glfw
I was able to solve my problem and, in case someone ever runs into similar situation hope this helps you.
There are two versions of glew32 -library in my system, glew32.a and glew32.dll.a.
glew32.a does not allow for using --static, glew32.dll.a does.
The two commands which compile succesfully, only first of which I've run are:
/usr/bin/i486-mingw32-g++ -I/usr/i486-mingw32/include -L/usr/i486-mingw32/lib main.cc -lglew32.dll -lglfw -lopengl32 --static
/usr/bin/i486-mingw32-g++ -I/usr/i486-mingw32/include -L/usr/i486-mingw32/lib main.cc -lglew32 -lglfw -lopengl32
Looking at my old compiling attempts, the problem was wrong order of libraries and that main.cc was after the libraries.
There is a program, called pkg-config that helps you to configure your compiler. See the manual pages for usage information, but, for this case, its output is:
-mwin32 -I/usr/i486-mingw32/include -L/usr/i486-mingw32/lib -lglfw -lglu32 -lopengl32 -lm -s -mwindows -e _mainCRTStartup
Try to compile with this, I guess it will work.
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
I am trying to compile a C++ program which invokes the ARPACK library.
My problem is that when everything is linked, some of the symbols in the ARPACK library do not get resolved. They are
__gfortran_transfer_integer
__gfortran_transfer_character
__gfortran_transfer_complex
__gfortran_compare_string
__gfortran_st_write_done
__gfortran_st_write
__gfortran_transfer_real
__gfortran_transfer_array
I did a brute force search on my lib directory, and found no library which provided all of these symbols. A couple of them are provided by libf77blas, and it looks like g95 has some similar symbols (with gfortran replaced by g95), but I am at a complete loss as to what else I might need to install. I am compiling my code with
g++-mp-4.5 -O3 -Wall -Wl,-search_paths_first -headerpad_max_install_names my.o -o my.out -L/opt/local/lib -larpack -lm -L/opt/local/lib -lgsl -lgslcblas -lm -lf77blas -llapack -larpack -lqblas -lsquack
and /opt/local/lib actually has all the libraries I reference.
Has anyone run into this problem, or can point to the solution?
add to linker -lgfortran .................