[Ubuntu 8.04] Linking Problem in Eclipse with Boost 1.41 Libraries
Hello all, My question is concerning the Boost installation process. I am currently working on a machine that has Ubuntu 8.04 LTS. I have downloaded the latest copy of Boost (1.41.0) and am trying to successfully install it. I have followed the procedures for building the libraries such as Filesystem / Regex / Thread / etc. using both the bootstrap, "easy", method and the "build custom binaries" method. I'm using Eclipse as my C++ development environment and I can create programs that use the Boost headers (the ones that do not require compilation - ie. Lambda) just fine. When I try to implement the sample program that incorporates [regex], I am able to compile and link just fine. I've set the include directory to ( /usr/local/boost_1_41_0/prefix/include - prefix was just the name I gave the folder), the library search path to ( /usr/local/boost_1_41_0/prefix/lib ) and the library I wanted to link to, [regex], using (boost_regex - I have also tried boost_regex-gcc##-mt ). As I said though, when I try to run the program, I get the result: ./boost_regex_test: error while loading shared libraries: libboost_regex.so.1.41.0: cannot open shared object file: No such file or directory I have not specified that I was using shared libraries, so I do not understand why it is trying to look for them. If anyone could please clarify why this is happening, I'd be more than greatful. Just as an aside, I also tried downloading and installing Boost from the Synaptic Package Manager that comes with Ubuntu 8.04. I'm able to use all of the libraries when I do this, but I'd rather not because the version of Boost is 1.34.1 (quite archaic) and has cause problems because member variables have evolved and some no longer exist. Thanks again for any and all help.
Brooks Garrison wrote:
Hello all,
My question is concerning the Boost installation process. I am currently working on a machine that has Ubuntu 8.04 LTS. I have downloaded the latest copy of Boost (1.41.0) and am trying to successfully install it. I have followed the procedures for building the libraries such as Filesystem / Regex / Thread / etc. using both the bootstrap, "easy", method and the "build custom binaries" method.
I'm using Eclipse as my C++ development environment and I can create programs that use the Boost headers (the ones that do not require compilation - ie. Lambda) just fine. When I try to implement the sample program that incorporates [regex], I am able to compile and link just fine. I've set the include directory to ( /usr/local/boost_1_41_0/prefix/include - prefix was just the name I gave the folder), the library search path to ( /usr/local/boost_1_41_0/prefix/lib ) and the library I wanted to link to, [regex], using (boost_regex - I have also tried boost_regex-gcc##-mt ).
As I said though, when I try to run the program, I get the result:
./boost_regex_test: error while loading shared libraries: libboost_regex.so.1.41.0: cannot open shared object file: No such file or directory
I have not specified that I was using shared libraries, so I do not understand why it is trying to look for them. If anyone could please clarify why this is happening, I'd be more than greatful.
Generally, you don't have to specify that you are using shared libraries. In fact, on modern Linux, every library is shared. I recommend you add /usr/local/boost_1_41_0/prefix/lib to LD_LIBRARY_PATH environment variable. In fact, I'd recommend creating ~/local directory and using that as prefix for installing anything you install from source. Then, add ~/local/bin to PATH and ~/local/lib to LD_LIBRARY_PATH, and you'll no longer have to tweak any settings when you install something new. HTH, Volodya
Volodya, Thanks for the quick response :)
Generally, you don't have to specify that you are using shared libraries. In fact, on modern Linux, every library is shared. I recommend you add /usr/local/boost_1_41_0/prefix/lib to LD_LIBRARY_PATH environment variable.
I've seen this workaround mentioned by a few people, but a lot of the things I've read say that you should -never- change the LD_LIBRARY_PATH environment variable, so I'd rather just be able to specify a link option or something else to get it to link properly.
In fact, I'd recommend creating ~/local directory and using that as prefix for installing anything you install from source. Then, add ~/local/bin to PATH and ~/local/lib to LD_LIBRARY_PATH, and you'll no longer have to tweak any settings when you install something new.
Ok I'll try this for now and see if it will at least work. Thanks for your suggestions.
Brooks Garrison wrote:
Volodya,
Thanks for the quick response :)
Generally, you don't have to specify that you are using shared libraries. In fact, on modern Linux, every library is shared. I recommend you add /usr/local/boost_1_41_0/prefix/lib to LD_LIBRARY_PATH environment variable.
I've seen this workaround mentioned by a few people, but a lot of the things I've read say that you should -never- change the LD_LIBRARY_PATH environment variable, so I'd rather just be able to specify a link option or something else to get it to link properly.
This is not a workaround. This is the standard way to make shared libraries installed into a custom location be available at runtime. I don't know which things you've read -- maybe they talk about more specific cases. Another alternative if to pass -R /usr/local/boost_1_41_0/prefix/lib option when compiling your library. You won't have to set LD_LIBRARY_PATH in that case, but passing the option every time can quickly become cumbersome. - Volodya
Volodya, Thanks again for your responses :)
I recommend you add /usr/local/boost_1_41_0/prefix/lib to LD_LIBRARY_PATH environment variable. This is not a workaround. This is the standard way to make shared libraries installed into a custom location be available at runtime.
In fact, I'd recommend creating ~/local directory and using that as prefix for installing anything you install from source. Then, add ~/local/bin to PATH and ~/local/lib to LD_LIBRARY_PATH, and you'll no longer have to tweak any settings when you install something new.
I did this, and was able to get the Regex example to work. However, when I went to test the Thread library (another that I am interested using), I run into another linking problem but not during compile time. I'm able to compile and link correctly: make -k all Building file: ../main.cpp Invoking: GCC C++ Compiler g++ -O0 -g3 -Wall -c -fmessage-length=0 -MMD -MP -MF"main.d" -MT"main.d" -o"main.o" "../main.cpp" Finished building: ../main.cpp Building target: boost_thread_test Invoking: GCC C++ Linker g++ -L/home/bgarrison/local/lib ./main.o -lboost_thread -o "boost_thread_test" Finished building target: boost_thread_test Build complete for project boost_thread_test but when I try to debug (using the debugger in Eclipse), I get the following message: /home/bgarrison/Code/boost_thread_test/Debug/boost_thread_test: error while loading shared libraries: libboost_thread.so.1.41.0: cannot open shared object file: No such file or directory This is strange to me because, I know the file it's looking for is in the directory specified by the -L parameter. :( Thanks for any and all advice. ~Brooks
Brooks Garrison wrote:
Volodya,
Thanks again for your responses :)
I recommend you add /usr/local/boost_1_41_0/prefix/lib to LD_LIBRARY_PATH environment variable. This is not a workaround. This is the standard way to make shared libraries installed into a custom location be available at runtime.
In fact, I'd recommend creating ~/local directory and using that as prefix for installing anything you install from source. Then, add ~/local/bin to PATH and ~/local/lib to LD_LIBRARY_PATH, and you'll no longer have to tweak any settings when you install something new.
I did this, and was able to get the Regex example to work. However, when I went to test the Thread library (another that I am interested using), I run into another linking problem but not during compile time. I'm able to compile and link correctly:
make -k all Building file: ../main.cpp Invoking: GCC C++ Compiler g++ -O0 -g3 -Wall -c -fmessage-length=0 -MMD -MP -MF"main.d" -MT"main.d" -o"main.o" "../main.cpp" Finished building: ../main.cpp
Building target: boost_thread_test Invoking: GCC C++ Linker g++ -L/home/bgarrison/local/lib ./main.o -lboost_thread -o "boost_thread_test" Finished building target: boost_thread_test
Build complete for project boost_thread_test
but when I try to debug (using the debugger in Eclipse), I get the following message:
/home/bgarrison/Code/boost_thread_test/Debug/boost_thread_test: error while loading shared libraries: libboost_thread.so.1.41.0: cannot open shared object file: No such file or directory
This is strange to me because, I know the file it's looking for is in the directory specified by the -L parameter. :(
As I have explained earlier, the -L option to the static linker has nothing to do with dynamic linker. What is the output of ls -l /home/bgarrison/local/lib/libboost_thread* ? And did you set LD_LIBRARY_PATH this time? If so, what exact commands did you use? Did you use 'export'? - Volodya
Volodya,
As I have explained earlier, the -L option to the static linker has nothing to do with dynamic linker. What is the output of
ls -l /home/bgarrison/local/lib/libboost_thread*
bgarrison@STK:~$ ls -l /home/bgarrison/local/lib/libboost_thread* -rw-r--r-- 1 root root 166080 2009-12-01 10:57 /home/bgarrison/local/lib/libboost_thread.a lrwxrwxrwx 1 root root 25 2009-12-01 10:56 /home/bgarrison/local/lib/libboost_thread.so -> libboost_thread.so.1.41.0 -rwxr-xr-x 1 root root 85176 2009-12-01 10:56 /home/bgarrison/local/lib/libboost_thread.so.1.41.0
? And did you set LD_LIBRARY_PATH this time? If so, what exact commands did you use? Did you use 'export'?
Yes I did. Sorry for the confusion. In my .bashrc file (~/.bashrc), I added # append to LD_LIBRARY_PATH LD_LIBRARY_PATH=/home/bgarrison/local/lib:$LD_LIBRARY_PATH export LD_LIBRARY_PATH to the end and saved it. Thanks again for your help and sorry for being so new at this :( Brooks
Brooks Garrison wrote:
Volodya,
As I have explained earlier, the -L option to the static linker has nothing to do with dynamic linker. What is the output of
ls -l /home/bgarrison/local/lib/libboost_thread*
bgarrison@STK:~$ ls -l /home/bgarrison/local/lib/libboost_thread* -rw-r--r-- 1 root root 166080 2009-12-01 10:57 /home/bgarrison/local/lib/libboost_thread.a lrwxrwxrwx 1 root root 25 2009-12-01 10:56 /home/bgarrison/local/lib/libboost_thread.so -> libboost_thread.so.1.41.0 -rwxr-xr-x 1 root root 85176 2009-12-01 10:56 /home/bgarrison/local/lib/libboost_thread.so.1.41.0
? And did you set LD_LIBRARY_PATH this time? If so, what exact commands did you use? Did you use 'export'?
Yes I did. Sorry for the confusion. In my .bashrc file (~/.bashrc), I added
# append to LD_LIBRARY_PATH LD_LIBRARY_PATH=/home/bgarrison/local/lib:$LD_LIBRARY_PATH export LD_LIBRARY_PATH
to the end and saved it.
Ok, and are you sure this file has any effect? Couple weeks ago, when I was still on 8.04, it had something called 'dash' as default shell. What does echo $LD_LIBRARY_PATH in the terminal say? What does: LD_LIBRARY_PATH=/home/bgarrison/local/lib:$LD_LIBRARY_PATH your_program do? - Volodya
Volodya,
Ok, and are you sure this file has any effect? Couple weeks ago, when I was still on 8.04, it had something called 'dash' as default shell.
The default shell I'm using is Terminal 2.22.1.
What does echo $LD_LIBRARY_PATH in the terminal say?
bgarrison@STK:~$ echo $LD_LIBRARY_PATH /home/bgarrison/local/lib:/usr/local/cuda/lib:
What does: LD_LIBRARY_PATH=/home/bgarrison/local/lib:$LD_LIBRARY_PATH your_program do?
The program executes as expected if I do this, but it also works if I execute it through the terminal by doing ./<program> so it seems that I -am- linking to the correct libraries. The problem seems to be that the debugger is trying to link with libraries it cannot find. I'd really hate to have to debug through printfs but that may be my only alternative if I cannot figure out how to set up the debugger correctly in Eclipse CDT. Thanks again for all of your help. ~Brooks
Brooks Garrison wrote:
Volodya,
Ok, and are you sure this file has any effect? Couple weeks ago, when I was still on 8.04, it had something called 'dash' as default shell.
The default shell I'm using is Terminal 2.22.1.
What does echo $LD_LIBRARY_PATH in the terminal say?
bgarrison@STK:~$ echo $LD_LIBRARY_PATH /home/bgarrison/local/lib:/usr/local/cuda/lib:
What does: LD_LIBRARY_PATH=/home/bgarrison/local/lib:$LD_LIBRARY_PATH your_program do?
The program executes as expected if I do this, but it also works if I execute it through the terminal by doing ./<program> so it seems that I -am- linking to the correct libraries. The problem seems to be that the debugger is trying to link with libraries it cannot find. I'd really hate to have to debug through printfs but that may be my only alternative if I cannot figure out how to set up the debugger correctly in Eclipse CDT.
It could be that CDT is unwilling to pass that variable to your program. Does setting LD_LIBRARY_PATH to /home/bgarrison/local/lib in the "Environment" tab of the debugger configurations dialog in CDT improves anything? - Volodya
Volodya,
It could be that CDT is unwilling to pass that variable to your program. Does setting LD_LIBRARY_PATH to /home/bgarrison/local/lib in the "Environment" tab of the debugger configurations dialog in CDT improves anything?
That was the problem. I was not setting LD_LIBRARY_PATH in the Environment tab. Thanks for all of your assistance :) ~Brooks
participants (2)
-
Brooks Garrison -
Vladimir Prus