I have a llvm module that i've dumped as bitcode file with llvm::WriteBitcodeToFile. I want to turn this bitcode file into an native dynamically loadable library that contains the functions in the module.
How do i do this? i tried using llc for this, but this produces code that apparently is not relocatable, since after doing the following steps:
llc -enable-pie -cppgen=functions -filetype=asm executableModule -o em.s
then, assemblying with gnu as into an object file:
as -o mylib.o em.s
finally, trying to produce a shared library with:
gcc -shared -o libmyfile.so -fPIC mylib.o
fails with the error:
/usr/bin/ld: error: mylib.o: requires dynamic R_X86_64_PC32 reloc against 'X.foo' which may overflow at runtime; recompile with -fPIC
collect2: ld returned 1 exit status
You need to setup relocation model. Something like -llc -relocation-model=pic. Do not use PIE, because it's for executables, not for libraries. Also, -cppgen does not make any sense here, it's for cpp backend only.
Related
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 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 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
I downloaded a software framework from the Data Prefetching Championship website (http://www.jilp.org/dpc/) and installed on a computer with the Ubuntu OS, 64 bit. I followed all of the instructions for unpacking the compressed file, and entered the "make" command to compile and this is what I received:
g++ -Wl,-u,main -g -shared -Wl,-Bsymbolic -Wl,--version-script=/grads/hhoffman/Documents/ELE_591/PREF_KIT/pin-2.5-22247-gcc.4.0.0-ia32_intel64-linux/source/include/pintool.ver -L/grads/hhoffman/Documents/ELE_591/PREF_KIT/pin-2.5-22247-gcc.4.0.0-ia32_intel64-linux/Lib/ -L/grads/hhoffman/Documents/ELE_591/PREF_KIT/pin-2.5-22247-gcc.4.0.0-ia32_intel64-linux/ExtLib/ -L/grads/hhoffman/Documents/ELE_591/PREF_KIT/pin-2.5-22247-gcc.4.0.0-ia32_intel64-linux/extras/xed2-intel64/lib -L/grads/hhoffman/Documents/ELE_591/PREF_KIT/pin-2.5-22247-gcc.4.0.0-ia32_intel64-linux/intel64/lib -L/grads/hhoffman/Documents/ELE_591/PREF_KIT/pin-2.5-22247-gcc.4.0.0-ia32_intel64-linux/intel64/lib-ext -o bin/CMPsim.usetrace ./bin/libCMPsim64.a ./src/prefetch/sample_prefetcher.o -lpin -lxed -ldwarf -lelf -ldl /usr/lib/x86_64-linux-gnu/libz.a
/usr/bin/ld: /usr/lib/x86_64-linux-gnu/libz.a(gzio.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
/usr/lib/x86_64-linux-gnu/libz.a: could not read symbols: Bad value
collect2: ld returned 1 exit status
make: *** [CMPsimpref64] Error 1
The problem, I believe, is with the libz.a file. Help?
I do not know how you compile this application, but you should add -fPIC to the compilation flags (CFLAGS and CXXFLAGS) of C/C++ files and recompile the application.
I also faced same problem mentions above but I am able to solved it with scientific linux 5.4 with gcc 4.1 configuration and I did one mistake when we have to set path up to prefetch kit. There was '$' sign which we have to remove while setting path for that PREF_KIT
On OSX 10.6.4 with i686-apple-darwin10-g++-4.2.1 compiling using TextMate and a Makefile which in the first place has been made für a Linux and I am trying to translate for OSX.
When compiling a c++ project I get the "can't link with a main executable" error:
g++ -Wall -g -I ~/svnX-Repository/axp-Projekte/xrlfupa/trunk/src/ -I ~/svnX-Repository/boost_1_44_0 -I /opt/local/var/macports/software/boost/1.44.0_0/opt/local/lib/ -I /opt/local/var/macports/software/gsl/1.14_0/opt/local/include/ -o xrfLibTest xrfLibTest.o excitFunctions.o xrfFunctions.o filterFunctions.o detectorFunctions.o -L/opt/local/var/macports/software/boost/1.44.0_0/opt/local/lib/ -L/opt/local/var/macports/software/gsl/1.14_0/opt/local/lib/ -lm -lxrlTUB -lboost_serialization -lgsl -lgslcblas # Debug 1
ld: in /usr/local/lib/libxrlTUB.so, can't link with a main executable
collect2: ld returned 1 exit status
make: *** [prog] Error 1
The library that is mentioned (libxrlTUB.so) is in its place (/usr/local/lib/libxrlTUB.so) but, possibly that is where the problem came from, the libxrlTUB.so has been compiled by myself beforehand as well.
The compile process went through, it was generated by swig, though there was a warning:
g++ -arch x86_64 -m32 -g -fpic -I /usr/include/python2.6 -c PyXrl_wrap.cxx
In function 'void SWIG_Python_AddErrorMsg(const char*)':
warning: format not a string literal and no format arguments
which, as far as I could find out, shouldnt be a problem. (Or is it?)
Unfortunately this whole thing is part of a project from the university. Actually I am supposed to write an X-ray-analysis script in python, which would be fine, if... well if I wouldn't be expected to use the librarys that are meant to result from this c++ project.
(Afterwards they should be used via import in python.)
I am not really experienced with c++, neither with compiling on OSX systems. So far I have been bothering with scipting (python, bash, etc). So Maybe I am just missing something simple. Hopefully someone can give me an hint where I can continue reading in order to deal with the above "can't link with a main executable" error...
Thanx in advance,
Liam
The error message is telling you the problem—it is that /usr/local/lib/libxrlTUB.so is not a shared library; it's an executable. You can't link against an executable. Probably whatever build process you used for libxrlTUB.so didn't understand how to build shared libraries on the Mac (it's more suspect because .dylib is the correct extension to use.)
Take a look at Apple's documentation on compiling dynamic libraries. You can use file to make sure your output is of the correct type, for example:
% gcc -c foo.c
% gcc -dynamiclib foo.o -o foo.dylib
% file foo.dylib
foo.dylib: Mach-O 64-bit dynamically linked shared library x86_64
Without -dynamiclib you end up with an executable, which may be the problem you've run into.