The thing is, recently I installed a new version of boost on my ubuntu.. I had 1.46 and now I have 1.56. The problem I am facing is now some of the programs wont run since apparently they require:
error while loading shared libraries: libboost_program_options.so.1.46.1: cannot open shared object file: No such file or directory
is there a bypass around this. How to solve the problem ?
Boost versions are not binary compatible. That application needs boost-1.46.1 and it cannot use any other version.
Either install boost-1.46.1 or recompile and re-link your applications against the available boost version.
Related
I recently upgraded my homebrew-installed packages, and after "Trinity-rnaseq" upgraded from 2.4 to 2.5, I received the following warning"
Warning: homebrew/science/trinity dependency boost was built with a different C++ standard library (libc++ from clang). This may cause problems at runtime.
I'm somewhat new to homebrew as a whole, and was wondering what the safest way to fix the boost dependency would be, if it is even necessary.
Thank you!
Rebuild boost and then anything that depends on boost and then your project. And yes, if any of that uses boost as part of a public interface it can easily be a problem.
I've compiled a Linux package on ubuntu 12.04 which uses boost and on this system i have boost 1.46. I tried to run the compiled release on another system and it complains that it can't find libboost_system.so.1.46.1. That system has boost 1.49 installed. How do I compile so that the program uses whatever version of boot exists instead of the specific version on the development machine.
You cannot expect your program to work with a different version of the library.
The fact that there are /different/ versions implies that they're /not the same/.
As mentioned, either
statically link to your specific version, or
you can ship the shared libraries (as long as you put them in a app-specific location and make sure you find them at runtime). Incidentally, see the second example here: How to compile boost async_client.cpp for the relevant linker options to use a custom library (it assumes the same location is to be used at runtime (rpath)
I'm building my program on my computer, on which libtiff.so -> libtiff.so.5.
And then pushing the builds on another machine on which libtiff.so -> libtiff.so.4.
At runtime, my program exists : « error while loading shared libraries: libtiff.so.5: cannot open shared object file: No such file or directory ».
I cannot upgrade the other machine, and I would like to avoid compiling on a virtual machine (with the same linux version than the executing machine). Therefore, I would like to force the compiler to use the libtiff.so.4 instead of libtiff.so.5.
I have libtiff.so.4 installed on my computer (as well as libtiff.so.5). How can I force the linkage with this version instead of the newer version. I thought about moving the libtiff.so -> libtiff.so.4, but I'm afraid of breaking my system if it needs the latest version (apt-get purge libtiff5 gives an error because some other package needs it).
Is it possible to link with an older (installed) version of a library? If yes, how?
And is it harmfull to change the symbolic link of libtiff.so to the older version? If not, will it solve my issue?
You can use this syntax to link to a specific version of a library:
gcc [other options] -l:libtiff.so.4
You do not need to specify a path; the usual directories are searched in order to find the library.
Note: as Michael Wild mentioned, you should have the header files for that version installed instead of the newest ones.
As others have mentioned, you can force the linker by specifying the full versioned name, or even the absolute path.
However, I would strongly advice against doing so. The problem is, that the installed headers correspond to the newer version of the library. If there have been API/ABI-breaking changes between these library versions, the program might work, crash intermittently, or if you're lucky, not work at all.
Instead you should temporarily install the development package that corresponds to the libtiff.so.4 library. If on Debian/Ubuntu or similar, this would be the libtiff4-dev package.
Specify the full path to the .so: instead of -ltiff pass /lib64/libtiff.so.4 to the linker.
You see that error when application is running. So you can either stop your application and then exrract your library tar file. Or, force to link the lib file to the newer version after you extract. In second case, you will use something like:
ln -fs libversionname libfile
Example:
ln -fs libomyapp.1.1.3 libomyapp.lib
This links your libomyapp.lib to the version specified. This can be your older vsersion or your newer version.
But as said, best way to work is to bring down your application to properly match to the expected lib functionality to work without errors or issues.
I am building a unix c++ program that calls boost, but when i try to run it i get
error while loading shared libraries: libboost_filesystem.so.1.42.0: cannot open shared object file: No such file or directory.
I didn't use to get this error before ( even though i was already calling boost ) , though i don't know what triggered the change. Anyway - doing ldd on the binary, it indeed shows that the library is missing.
I guess the solution would be to add in the LD_LIBRARY_PATH a link to the library containing the .so file - but i can't find it. Where should it be? Is this the right solution?
Note that i don't have sudo privelages on my computer, so i can only change user settings - And also that i'm a linux newb so please try to explain simply...
I think the problem is that you have linked to a very specific version of Boost (1.42.0 in this case). This worked as long as Boost existed in that exact version on your system, but as soon as an update to a more recent version of Boost happened, the linked library could no longer be found.
You might want to adjust your Makefile to link to a more generic version of libboost_filesystem.so.
As far as I know ERS C++ Builder 2010 comes with Boost libraries. During installation it will also install Boost libraries.
As new libraries will be realeased or modified(optimized), it gets me to upgrade to the latest version.
So i'm asking can i do this by replacing boost directory?
It's not as simple as updating the $(CG_BOOST_ROOT) directory with a new boost.
See this question previously asked on SO.
Someone could put the effort in, and it could be possible to run many of the latest boost libraries with bcc. (and hopefully submit those changes back to boost) That hasn't really happened yet.
However, even with a Herculean effort there are some constructs used by boost that bcc just doesn't handle yet, so there will be some boost libraries that won't be usable by bcc.