I am running across a problem similar to Boost linkage error in Eclipse. I have a program which includes boost/filesystem.hpp.
When I try to compile my program with eclipse I get the following error.
g++ -libboost_system -o "crcTools2" ./crcThing.o -lboost_filesystem -lboost_system-mt
/opt/centos/devtoolset-1.1/root/usr/libexec/gcc/i686-redhat-linux/4.7.2/ld: cannot find -libboost_system
collect2: error: ld returned 1 exit status
As you can see, I am compiling using g++ 4.7.2 from devtoolset-1.1 and am running CentOs. The boost version is 1.57.
I have tried with both boost_system and boost_system-mt as my libraries. When I run
ldconfig -v | grep -i "libboost_system"
I get
libboost_system-mt.so.5 -> libboost_system-mt.so.5
libboost_system.so.5 -> libboost_system.so.5
I'm sure there's something wrong with my configuration but I can't figure out what it is.
It's complaining about -libboost_system you put at the beginning. This is incorrect linker option.
Related
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 read V8 hello world example, and follow the steps in the document to build v8 successfully.
But when I compile the example code, link error occured. Here comes my computer detail and error prompts.
OS Ubuntu 13.10 amd64
GCC (Ubuntu/Linaro 4.8.1-10ubuntu9) 4.8.1
Compile command:
g++ -Iinclude hello_world.cc -o hello_world -Wl,--start-group out/native/obj.target/{tools/gyp/libv8_{base.x64,snapshot},third_party/icu/libicu{uc,i18n,data}}.a -Wl,--end-group -lrt
Error prompts
/usr/bin/ld: /home/leon/Documents/v8/v8/out/native/obj.target/v8_base.x64/src/platform/mutex.o: undefined reference to symbol 'pthread_mutexattr_settype##GLIBC_2.2.5'
/lib/x86_64-linux-gnu/libpthread.so.0: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
The error suggests that you need to add the pthread library to your link command. Just append -lpthread.
(It's a bit odd that it identifies exactly which library you need, then tells you it refuses to use it because you didn't list it on the command-line...)
I have been trying to compile and link Qt5, which means I have been messing with some ldconfig and include path defaults that I don't completely understand. I will do my best to limit my question to a very specific one, as my priority is fixing my compiler.
I have used a command to try
`gcc -print-prog-name=cc1plus` -v
ignoring nonexistent directory "/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/include/c++/4.7
/usr/include/c++/4.7/x86_64-linux-gnu
/usr/include/c++/4.7/backward
/usr/lib/gcc/x86_64-linux-gnu/4.7/include
/usr/local/include
/usr/lib/gcc/x86_64-linux-gnu/4.7/include-fixed
/usr/include
End of search list.
There is a problematic line at the beginning, about ignoring a non-existent directory when searching for the header. Unfortunately, this is exactly where g++ thinks it's a good idea to look for crt1.o, which I assume is some sort of binary that morphs the main() function into an executable:
g++ -Isrc --std=c++11 -g -c -o src/tissuecell.o src/tissuecell.cpp
g++ -Isrc --std=c++11 -g -c -o src/analyze.o src/analyze.cpp
g++ -o TissueCells src/tissuecell.o src/analyze.o
/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../x86_64-linux-gnu/crt1.o: In function `_start':
(.text+0x20): undefined reference to `main'
collect2: error: ld returned 1 exit status
My compiler has not done this until a few hours ago (previously, it would compile!), and what comes to mind in terms of "irreversible commands" that I typed was a single:
sudo ldconfig
Can anyone get me out of this terrible pit of linking and compilation problems, and remove this pesky line from my include path?
Some questions that you might also be able to answer that would make me very happy:
How do I view & edit the paths that my compiler searches for includes? (Not -I)
How do I view & edit the paths that my compiler searches for libraries? (Not -L, and ld should be able to find the libraries as it needs them)
What relation does ld have to this whole process, and is there a way to pass ld some flags through my g++ call (for example, -rpath)?
Oh gosh, this is embarrassing. My problem was that I did not fix my Makefile after giving up on the new build; the error was coming from a lack of main() function in my codebase.
The following command allowed me to test my compiler for internal errors:
echo "int main() { return 0; }" > /tmp/test.c; gcc -v /tmp/test.c
I pulled back to an old commit on my git, and got my code to compile, which served as a good double-check on my compiler's sanity.
First of all you can run gcc(g++) with "-v" option, for example:
echo "int main() { return 0; }" > /tmp/test.c
gcc -v /tmp/test.c
You find in ouput the things like:
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/include/g++-v4
plus
#include <...> search starts here:
/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/include
/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/include-fixed
/usr/include
LIBRARY_PATH=/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/:/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/../../../../x86_64-pc-linux-gnu/lib/:/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/../../../:/lib/:/usr/lib/
and many other stuff.
The second variant you can use "strace -f" in front of your command, grep ouput with pattern open to find out where and what file is used.
It looks like g++/gcc-mingw is installed but I can't tell how to use it.
I am building a C source file with a windows main proc and I get this error:
g++-3 -mwindows -L/usr/lib/gcc/i686-pc-mingw32 -lmingw32 winmain.c
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/bin/ld:
cannot find -lmingw32 collect2: ld returned 1 exit status
Or
$ g++-3 -mwindows -L/usr/lib/gcc/i686-pc-mingw32 winmain.c
/tmp/ccyLGxkn.o:winmain.c:(.text+0x21): undefined reference to
`MainWndProc(HWND__*, unsigned int, unsigned int, long)#16' collect2:
ld returned 1 exit status
If I do a list directory on the installed libraries I see this:
$ ls /usr/lib/gcc/ i686-pc-cygwin/ i686-pc-mingw32/
Note: 'i686-pc-mingw32' How do I compile using the mingw32 libraries?
Also, I installed the package: 'gcc-mingw-g++' through the cygwin setup.exe utility, I just don't know how to use it?
Note: I am mostly working with 'cygwin', I would prefer NOT to install the full ming install?
There are actually two sets of projects, the libraries and the actually toolchain. I installed the libraries and not the toolchain.
The libraries are: gcc-mingw-g++
mingw64-i686-gcc is the toolchain
I ran with this command and it worked correctly:
i686-pc-mingw32-g++
i686-w64-mingw32-g++
Or:
i686-w64-mingw32-g++ -mwindows -static -I/opt/jdk/include
-I/opt/jdk/include/win32 -Wl,--add-stdcall-alias -shared -o Hello.dll Hello.cpp
I've been banging my head fruitlessly against the wall attempting to include boost's thread functionality in my Eclipse C++ project on Ubuntu.
Steps so far:
Download boost from boost.org
./configure --with-libraries=system,thread
make
sudo make install
sudo ldconfig -v
In the eclipse project, set the include directory to:
/usr/local/include/boost-1_38/
In the linker set the library(-l) to "boost_thread"
Set the search path (-L) to
/usr/local/lib
Linker runs, returns with ld error
/usr/bin/ld: cannot find -lboost_thread
as follows:
Invoking: GCC C++ Linker
g++ -L/usr/local/lib -o"boostHello3" ./src/boostHello3.o -lboost_thread
/usr/bin/ld: cannot find -lboost_thread
collect2: ld returned 1 exit status
Here are relevant entries from /usr/local/lib:
libboost_system-gcc43-mt-1_38.a
libboost_system-gcc43-mt-1_38.so
libboost_system-gcc43-mt-1_38.so.1.38.0
libboost_system-gcc43-mt.a
libboost_system-gcc43-mt.so
libboost_thread-gcc43-mt-1_38.a
libboost_thread-gcc43-mt-1_38.so
libboost_thread-gcc43-mt-1_38.so.1.38.0
libboost_thread-gcc43-mt.a
libboost_thread-gcc43-mt.so
Here are the contents of /etc/ld.so.conf
include /etc/ld.so.conf.d/*.conf
/usr/local/lib
How is the linker missing this?
Well, the linker tries to find a library called "libboost_thread.a" (or "libboost_thread.so") in its search path, which you apparently don't have.
Either create an appropriate link, or use "-lboost_thread-gcc43-mt"
Your linker line should be saying -lboost_thread-gcc43-mt-1_38.