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
Related
I am trying to cross compile a c++ code for a 64-bit architecture arm device using the ARM cross compiler toolchain from here https://www.acmesystems.it/arm9_toolchain .
My compile command is
arm-linux-gnueabihf-gcc examples/neon_cartoon_effect.cpp utils/Utils.cpp -I. -Iinclude -std=c++11 -mfpu=neon -L/home/deeptihegde/ComputeLibrary/build -larm_compute -o build/neon_cartoon_effect
I get the below error
/home/deeptihegde/ComputeLibrary/build/libarm_compute.so: file not recognized: File format not recognized
collect2: error: ld returned 1 exit status
.
Is this a compiler issue? Did I link it incorrectly?
Any help would be appreciated, thanks.
I think the problem is you are trying to link 32bit application(neon_cartoon_effect) with 64bit Library (libarm_compute.so).
I have been using gtests for unit testing a personal project. Last week I upgraded to the LTS version of Linux Mint. Unfortunately, after that event, I haven't been able to compile my project due to gtests linking problems.
The following error is being issued:
/usr/bin/x86_64-linux-gnu-ld: build/tests/policies/roundrobin_tests.o: undefined reference to symbol '_ZN7testing4TestC2Ev'
/home/myuser/Documents/googletest-release-1.8.0/googletest/libgtest.so: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
I have generated both libgtest.so and libgtest_main.so through CMake 3.10.2. The gtest version is the release-1.8.0, the same I used to have before.
Those libraries are located in /usr/lib and the corresponding include folder has also been copied to /usr/include. I made sure that this location is in my ld path and that is not the problem.
My compiler is g++ v7.3.0 and the command Im using to compile the testes is:
g++ -std=c++14 -Wall -O3 -Iinclude build/tests/policies/roundrobin_tests.o -lgtest_main -pthread -o bin/policies/roundrobin_tests
I have tried altering the order of the elements in the command, explicitly adding -L/usr/lib and -I/usr/include without luck. A funny fact is that if I take off the -pthread flag, the error is still the same.
The same command was used before and the only difference is the compiler version I am using now as I used g++ 5.4.0 before. Any insights on how to solve this?
edit: Just tested the same process with g++ 5.4.0 and CMake 3.5 and the same problems ocurred.
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 build a specific program on Ubuntu 12.04 64 bit.
The program needs to be compiled 32 bits.
I installed the ia32-libs and gcc-multilib packages.
I managed to compile it on 3 different computers, but on this one, it fails with a weird error.
for some reason, libm.so is not picked up correctly, or something is wrong with the library.
This is the actual compilation line that fails as it was extracted from the Makefile.
gcc -o x86_32_obj/foo x86_32_obj/foomain.o -m32 -fPIC -fno-stack-protector -lc -lgcc -lm -lpthread -lrt -lstdc++ ../libfoo/lib/./libfii.x86_32.a
This is the output
/usr/bin/ld: ../libfoo/lib/./libfoo.x86_32.a(NK_Meas.o): undefined reference to symbol 'expf##GLIBC_2.0'
/usr/bin/ld: note: 'expf##GLIBC_2.0' is defined in DSO /usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../lib32/libm.so so try adding it to the linker command line
/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../lib32/libm.so: could not read symbols: Invalid operation
collect2: ld returned 1 exit status
make[1]: *** [foo] Error 2
make: *** [foo] Error 2
I have seen errors such as this in relation to the linking order. It may be possible to address the error by placing the libm linking directive at the very end of your linking configuration.
These interdependencies are very much system dependent, which is probably why the same command works on other systems.
Found the problem.
Apparently, the library file I was linking against was compiled using a different version of GCC.
I don't know how exactly it's related, but once I replaced the gcc compiler to the one used with the library it worked.
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.