I have a problem: I wrote code using Boost (locks.hpp). My server is running x64 Ubuntu (Linux). When i compile this code with -m64, it builds fine. But when I try to compile for -m32, I get these errors:
g++ -fPIC -m32 -shared -Wl,-soname,test.so -ldl -o test.so test.cpp -lboost_thread
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.4.5/../../../libboost_thread.so when searching for -lboost_thread
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.4.5/../../../libboost_thread.a when searching for -lboost_thread
/usr/bin/ld: skipping incompatible //usr/lib/libboost_thread.so when searching for -lboost_thread
/usr/bin/ld: skipping incompatible //usr/lib/libboost_thread.a when searching for -lboost_thread
/usr/bin/ld: cannot find -lboost_thread
collect2: ld returned 1 exit status
What am I doing wrong? Thanks!
Try installing the 32-bit boost package:
sudo apt-get install libboost-thread-dev:i386
You need a 32 bit version of the thread library. The answer to your question is already on stackoverflow.com. Use the address-model option when you build boost from source. Boost provides great documentation for building on Linux.
bjam address-model=32
Related
I am using Fedora 28 with Eclipse Version: Oxygen.3a.
I have already installed the add-on for LLVM-Clang from "Install new software". I am using GCC/G++ 8.1.1.
I built Clang using ninja build system, and it works perfectly fine from command line. I am interested in LibTooling library, so, it serves my purpose. Then, I was trying to setup Eclipse with Clang (mainly for easy debugging), but it Eclipse always gives me linker errors.
I tried 2 solutions:
Followed this thread Unable to install LLVM toolchain for Eclipse CDT. I made a hello world project, and I get the errors:
clang++ -I/home/hassan/Tools/llvm-clang/llvm/include -O0 -emit-llvm -g3 -Wall -c -fmessage-length=0 -std=c++0x -o src/clang_test.bc ../src/clang_test.cpp
clang++ -L/usr/lib/gcc/x86_64-redhat-linux/8/32/ -L/home/hassan/Tools/llvm-clang/build/bin -o clang_test src/clang_test.bc -lstdc++
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-redhat-linux/8/32//libstdc++.so when searching for -lstdc++
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-redhat-linux/8/32//libstdc++.so when searching for -lstdc++
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-redhat-linux/8/32//libgcc_s.so when searching for -lgcc_s
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-redhat-linux/8/32//libgcc.a when searching for -lgcc
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-redhat-linux/8/32//libgcc_s.so when searching for -lgcc_s
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-redhat-linux/8/32//libgcc.a when searching for -lgcc
I set the include paths/lib paths to my already built (ninja build system) directory. It compiles fine without any problems, but I get linker errors, e.g., llvm::outs() could not be identified.
If anyone can point me in the right direction, that would be great.
Thanks.
I have a very similar issue to the one presented in how to dynamically link to local copy of libc.so.6, libstdc++.so.6 on system with old version of gcc and I followed the answer provided there. To summarize, the issue is that I have code written using C++11 and the cluster sysadmin won't upgrade the gcc compiler to a version which supports C++11. I did a manual install of gcc4.9 in my home directory (using --prefix=$HOME). I compile my code with the following flags:
-I/home/stroberg/include -L/home/stroberg/lib -lc -lstdc++ -llapack -lblas -O3 -std=C++11
I also set
export LD_LIBRARY_PATH=/home/stroberg/lib:$LD_LIBRARY_PATH
The compilation goes fine until it gets to the linking stage, where I get the following errors:
/usr/bin/ld: skipping incompatible /home/stroberg/lib/libstdc++.so when searching for -lstdc++
/usr/bin/ld: skipping incompatible /home/stroberg/lib/libstdc++.a when searching for -lstdc++
/usr/bin/ld: skipping incompatible /home/stroberg/lib/libstdc++.so when searching for -lstdc++
/usr/bin/ld: skipping incompatible /home/stroberg/lib/libstdc++.a when searching for -lstdc++
/usr/bin/ld: skipping incompatible /home/stroberg/lib/libgcc_s.so when searching for -lgcc_s
/usr/bin/ld: skipping incompatible /home/stroberg/lib/libgcc_s.so when searching for -lgcc_s
Any ideas what could be causing the problem? I'm also using the armadillo package (also a local version) is that makes any difference.
Thanks.
I got it working, so I figured I should post what I did. Compiling with
-I$(HOME)/include -L$(HOME)/lib -lblas -llapack -lgsl -lglsblas -O3 -std=c++11
seemed to do the trick. Wish I knew exactly what fixed the problem, but I hope this helps.
It was a long long way, but I managed to include a shared file (libpi_pi_gcs2.so) included into C++ code under Linux Mint 17 Cinnamon 64-bit. Now as the dust is saddled I have a question left... let me summarize:
I copied libpi_pi_gcs2.so in usr/local/lib.
Trying to compile main.cpp with
g++ -Wall -o test main.cpp -lpi_pi_gcs2
faild, returning
/usr/bin/ld: skipping incompatible //usr/local/lib/libpi_pi_gcs2.so when searching for -lpi_pi_gcs2
/usr/bin/ld: cannot find -lpi_pi_gcs2
collect2: error: ld returned 1 exit status
I talked with my flatmate, and he guessed maybe the shared library is only 32bit compatible.
Using -m32 let me take a step forward! But yielding new errors.
I googled and it seemed like I needed C32 std libraries. And I installed:
apt-get install ia32-libs
Again the old error messages disappeared and new one arose, after googling around I installed:
apt-get install g++-multilib
Trying to compile it now using
g++ -Wall -o test -m32 main.cpp -lpi_pi_gcs2
Let to the error messages:
//usr/local/lib/libpi_pi_gcs2.so: undefined reference to `dlsym'
//usr/local/lib/libpi_pi_gcs2.so: undefined reference to `dlopen'
//usr/local/lib/libpi_pi_gcs2.so: undefined reference to `dlclose'
The solution was the following command:
g++ -Wall -o test -m32 main.cpp -lpi_pi_gcs2 -ldl
Now my question:
Is it necessary to explicitly state -ldl i.e. link with libdl.so because the -m32 flag declares everything what follows to be 32bit and hence the linker would without explicitly
writing -ldl search for a 32bit libdl.so? I guess mine is 64 bit I am working on a 64bit system.
What do you think? More details and background informations are appreciated.
Greetings,
newandlost
I'm trying to compile x32 LD_PRELOAD on x64 platform(Ubuntu), my command:
g++ -fPIC -m32 -shared -Wl,-soname,test.so -ldl -o test.so test.cpp
But i'm getting error:
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.4.5/libstdc++.so when searching for -lstdc++
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.4.5/libstdc++.a when searching for -lstdc++
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.4.5/libstdc++.so when searching for -lstdc++
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.4.5/libstdc++.a when searching for -lstdc++
/usr/bin/ld: cannot find -lstdc++
collect2: ld returned 1 exit status
How can i fix that?
Thanks!
You need to install 32-bit development packages provided by your distribution. You are seeing this error because you do not have a 32-bit libstdc++ to link against.
Try installing Ubuntu's g++-multilib package.
I am trying to compile in a way such that the exec links to gcc statically. I presumed running bjam link=static runtime-link=static should do the trick ?
When I tried that I get the following errors like :
...failed gcc.link TGT/bin/gcc-4.5.1/debug/link-static/runtime-link-static/datagen...
gcc.compile.c++ TGT/bin/gcc-4.5.1/release/link-static/runtime-link-static/base_data_gen.o
gcc.link TGT/bin/gcc-4.5.1/release/link-static/runtime-link-static/datagen
/usr/bin/ld: cannot find -lstdc++
/usr/bin/ld: cannot find -lm
/usr/bin/ld: cannot find -lc
collect2: ld returned 1 exit status
These don't come when I run bjam link=static.
Please advise ?
I belive that libstdc++ is intentionally not linked statically. Doing so is considered by many to be filled with peril (though I have not really heard a good reason). I do not think that there is a simple flag that you can add. For the gcc toolset you would add something like
-static-libgcc -Wl,-Bstatic -lstdc++
to your cxxflags for your build variant.