Boost linkage error in Eclipse - c++

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.

Related

Trying to link library to a file which uses OpenGL and linker not being able to find GL relevant file

So this is my output when i run
$ g++ main.c -lGL
/usr/bin/ld: cannot find -lGL
collect2: error: ld returned 1 exit status
however i DO have GL installed because it came with my graphics card driver which i downloaded from nvidia website namely the 346.72 for my graphics card 780ti
when i do a search i.e locate GL here is part of the response
...
/usr/include/GL
/usr/include/GL/freeglut.h
/usr/include/GL/freeglut_ext.h
/usr/include/GL/freeglut_std.h
/usr/include/GL/gl.h
/usr/include/GL/gl_mangle.h
/usr/include/GL/glcorearb.h
/usr/include/GL/glew.h
/usr/include/GL/glext.h
/usr/include/GL/glu.h
/usr/include/GL/glu_mangle.h
/usr/include/GL/glut.h
/usr/include/GL/glx.h
/usr/include/GL/glx_mangle.h
/usr/include/GL/glxew.h
/usr/include/GL/glxext.h
/usr/include/GL/glxint.h
/usr/include/GL/glxmd.h
/usr/include/GL/glxproto.h
/usr/include/GL/glxtokens.h
/usr/include/GL/internal
/usr/include/GL/wglew.h
/usr/include/GL/internal/dri_interface.h
/usr/include/GL/internal/glcore.h
...
/usr/lib/x86_64-linux-gnu/libEGL.so
/usr/lib/x86_64-linux-gnu/libEGL.so.1
/usr/lib/x86_64-linux-gnu/libEGL.so.346.72
/usr/lib/x86_64-linux-gnu/libGL.la
/usr/lib/x86_64-linux-gnu/libGL.so
/usr/lib/x86_64-linux-gnu/libGL.so.1
/usr/lib/x86_64-linux-gnu/libGL.so.346.72
/usr/lib/x86_64-linux-gnu/libGLESv1_CM.so
/usr/lib/x86_64-linux-gnu/libGLESv1_CM.so.1
/usr/lib/x86_64-linux-gnu/libGLESv1_CM.so.346.72
/usr/lib/x86_64-linux-gnu/libGLESv2.so
/usr/lib/x86_64-linux-gnu/libGLESv2.so.2
/usr/lib/x86_64-linux-gnu/libGLESv2.so.346.72
/usr/lib/x86_64-linux-gnu/libGLEW.so
/usr/lib/x86_64-linux-gnu/libGLEW.so.1.10
/usr/lib/x86_64-linux-gnu/libGLEW.so.1.10.0
/usr/lib/x86_64-linux-gnu/libGLU.a
/usr/lib/x86_64-linux-gnu/libGLU.so
/usr/lib/x86_64-linux-gnu/libGLU.so.1
/usr/lib/x86_64-linux-gnu/libGLU.so.1.3.1
/usr/lib/x86_64-linux-gnu/libQt5OpenGL.so.5
/usr/lib/x86_64-linux-gnu/libQt5OpenGL.so.5.2
/usr/lib/x86_64-linux-gnu/libQt5OpenGL.so.5.2.1
/usr/lib/x86_64-linux-gnu/libQtOpenGL.so.4
/usr/lib/x86_64-linux-gnu/libQtOpenGL.so.4.8
/usr/lib/x86_64-linux-gnu/libQtOpenGL.so.4.8.6
/usr/lib/x86_64-linux-gnu/mesa/libGL.so
....
which shows that it does exist
how do i link this with the linker?
The canonical way is to add the directory containing architecture-plattform specific libraries, like /usr/lib/x86_64-linux-gnu/ to the system linker path. To do this add it to /etc/ld.so.conf and rebuild the linker cache. Rebuilding the linker cache is done by executing ldconfig with superuser privileges.

scons linker error for system libs

I re-organized the directory tree of an existing project, making relevant Sconscript changes, and in so-doing I introduced the following linker error:
/bin/ld: note: '__cxa_free_exception##CXXABI_1.3' is defined in DSO /usr/lib64/libstdc++.so.6 so try adding it to the linker command line
/usr/lib64/libstdc++.so.6: could not read symbols: Invalid operation
collect2: error: ld returned 1 exit status
I found this thread and if I follow that advice and attempt to be explicit about the system libs it just kicks the can down the road (the ensuing error will be about libm and so on with other system libs).
Since this compiles fine without my reorganization, what could have been done to scons where it no longer links to system libs?
Nowhere in the existing SConstruct/Sconscript fileset is there any reference to linking against any of the system libs. This was automagically done by scons, but now that I have rearranged a few subprojects, I encounter the above error.
The libpath and rpath both include the following:
'/usr/lib64',
'/usr/lib64/mysql',
'/usr/local/lib',
Linker Command
gcc -o build/debug/icln/src/foo/fooCert/build/scons/fooCertFromFiles -Wl,-rpath=/usr/lib64 -Wl,-rpath=/usr/lib64/mysql -Wl,-rpath=/usr/local/lib -Wl,-rpath=/ws/build/debug/icmn/src/common -Wl,-rpath=../../../../engine/build/scons -Wl,-rpath=../../../../foo/build/scons -Wl,-rpath=../../../../kb/build/scons -Wl,-rpath=../../../../bar/build/scons -Wl,-rpath=../../../../tables/build/scons -Wl,-rpath=../../../../utils/build/scons -L/usr/lib64 -L/usr/lib64/mysql -L/usr/local/lib -Lbuild/debug/icmn/src/common -L/ws/icmn/src/common -Lbuild/debug/icln/src/engine/build/scons -Lsrc/engine/build/scons -Lbuild/debug/icln/src/foo/build/scons -Lsrc/foo/build/scons -Lbuild/debug/icln/src/kb/build/scons -Lsrc/kb/build/scons -Lbuild/debug/icln/src/bar/build/scons -Lsrc/bar/build/scons -Lbuild/debug/icln/src/tables/build/scons -Lsrc/tables/build/scons -Lbuild/debug/icln/src/utils/build/scons -Lsrc/utils/build/scons -lcengine -lbar -lfoo -lkb -lcutils -lCommon -ltables -lglog -lboost_date_time -lboost_serialization -lboost_system -lboost_filesystem -lmongoclient -lboost_thread -lpthread -lmysqlcppconn -lmysqlclient
Update: I noticed the call to build the final binary was to gcc, and not g++. I am still trying to determine why it suddenly switched to gcc instead of g++, but I think this is heading towards root cause.
How does scons determine whether to invoke CC vs CXX?
Solved: So because of the re-organization I performed, a call to Glob() was resolving to an empty list since I had changed the path to where the source files are.
The fix: I needed to update the Glob call to use new path to the source (the Sconscript and source files no longer co-reside in the same directory as they did before).
BEFORE
source = Glob('*.cc')
AFTER
source = Glob('../../src/*.cc')

Cannot find -libboost_system

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.

CodeBlocks cannot find shared libraries even when search paths are setup

I have a very basic C++ project in code blocks that makes use of glfw.so and two other libraries that are compiled to .so files from another project, libHorde3D.so and libHorde3DUtils.so. The latter are placed in the project root folder, while glfw is somewhere in my /usr/lib (I think).
I have added the project folder to the linker and compiler search paths in code blocks. I have added the libHorde3D.so and libHorde3DUtils.so as well as glfw.so to the Link Libraries in the Linker Settings tab. I thought that this would be enough based on the previous similar questions here on stackoverflow.
However when I press build:
ld cannot find -lHorde3D.so
ld cannot find -lHorde3DUtils.so
ld cannot find -lglfw.so
My system is Arch Linux 64 and I am using GCC.
I also tried bopying libHorde3D.so and libHorde3DUtils.so in /usr/lib and /usr/lib64 with no success.
P.S. All search paths are copied across the Debug and Release target.
Say, if the library name is libmylibrary.so, then linker option to link against that library would look like -lmylibrary. Note that lib prefix and .so suffix are not there — they are added automatically by the linker. In your case it seems like you specified the wrong name. Try removing .so from it, that should solve the problem.
Here is a simple demonstration of how to trigger the failure by making a similar mistake:
$ echo 'int main() { return 0; }' > test.c
$ gcc -o test ./test.c -lc
$ gcc -o test ./test.c -lc.so
/usr/bin/ld: cannot find -lc.so
collect2: ld returned 1 exit status
$
The first command succeeds and the second one (with incorrect library name) fails.
You must not pass ".so". The linker options are
-lHorde3D -lHorde3DUtils -lglfw
This way the linker will search for "libHorde3D.so" etc. in the library path(s).

/usr/bin/ld: cannot find -llibeststring.a

I am using festival TTS c++ API in my program.I have downloaded all files from http://www.cstr.ed.ac.uk/downloads/festival/2.0.95/
and install festival and speech_tools successfully on my UBUNTU 10.04
now when compile my c++ programme gcc gives error:
g++ -L/usr/lib -L/home/peeyush/Desktop/festival/src/lib -L/home/peeyush/Desktop/speech_tools/lib -o"peeyush" ./src/peeyush.o -llibeststring.a -llibestbase.a -llibestools.a -llibFestival.a
/usr/bin/ld: cannot find -llibeststring.a
collect2: ld returned 1 exit status
make: *** [peeyush] Error 1
so please help me to sort out this error.
-Thanks
Peeyush Chandel(INDIA)
When using the -l option, you don't specify the leading lib or trailing .a or .so parts of the name as they're assumed by the linker. You would want to use something like -leststring to pick it up (assuming that your -L path is set correctly.
Alternately you can specify the exact filename (so no -l, just libeststring.a) as part of the object list to link (make sure the order is right relative to your .o files), but I believe in that case you would have to specify the path as the linker won't know to search your -L path. Easiest is to use -l though.