Linux: executable cannot find shared library
I have compiled casablanca and have put -l:/~/path/to/lib/libcasablanca.so in my CMakeList.txt . I have build my application and I have got no errors. But when I run the executable it says:
./myproj: error while loading shared libraries: libcasablanca.so: cannot open shared object file: No such file or directory I have done it on another computer and it seems to work fine. Does anyone know what is the problem? How to fix this? I have no administrator access to this machine.
1 Answer 1
This is very simple: your library is not in the default system path from them the shared libraries are imported. During the compilation, the compile scripts solved these problems. In runtime, you have the LD_PRELOAD or LD_LIBRARY_PATH environment variables.
For example: an export LD_LIBRARY_PATH=/home/darkside/wunderprog/lib will extend the directoried searched for your libraries with the named directory. If there is your libcasablanca.so , you will get what you want.
Normally I use a /home//lib directory in my useronly accounts and set LD_LIBRARY_PATH from .profile .
If I do export LD_LIBRARY_PATH=/~/path/to/lib , does it removes the values existent in the variable? Or there is nothing in it?
@thedarksideofthemoon Yes, but normally it is empty (the system sharedlib search path isn’t there). If you have some important there, you can give him a colon-separated path list, just as we can see in $PATH : export LD_LIBRARY_PATH=/home/darkmoon/lib:/home/darkmoon/some_another/lib . or just so.
Where are package library and header files installed?
After downloading and installing a package in Ubuntu, how can I check where the library and header files were written to? I believe that this has something to do with the package’s .pc file, but I do not know how to find that file either. For example, I have downloaded the PCL (Point Cloud Library) package, and then in a sample CMakeLists.txt file, I have been given the following:
include_directories($) link_directories($) add_definitions($) Where are these environment variables defined, and how can I see them? If I compiled the libraries from source rather than through a package, will this be any different? Will a .pc file be created automatically?
That just returns an empty line. However, compiling my project as above works fine so it must be using the PCL libraries. Is it searching anywhere else?
If you installed a debian package you can see the content via dpkg -L
I had similar confusions. You can check to what values $ resolves to by using message command in your CMakeLists.txt i.e. add this line: message(«$) or message(«PCL_INCLUDE_DIRS = » $) . It will display the result when you run cmake .. Do the same for other macros/variables i.e. $ and $
2 Answers 2
If you install the package containing the libpcl development files
sudo apt-get install libpcl-dev You can list the installed files
an see the location of all headers.
. /usr/include/pcl-1.7/pcl/filters/fast_bilateral.h /usr/include/pcl-1.7/pcl/filters/voxel_grid_covariance.h /usr/include/pcl-1.7/pcl/filters/voxel_grid_occlusion_estimation.h /usr/include/pcl-1.7/pcl/filters/median_filter.h /usr/include/pcl-1.7/pcl/filters/crop_box.h /usr/include/pcl-1.7/pcl/filters/voxel_grid_label.h /usr/include/pcl-1.7/pcl/filters/covariance_sampling.h /usr/include/pcl-1.7/pcl/filters/random_sample.h /usr/include/pcl-1.7/pcl/filters/normal_refinement.h /usr/include/pcl-1.7/pcl/filters/project_inliers.h /usr/include/pcl-1.7/pcl/filters/fast_bilateral_omp.h /usr/include/pcl-1.7/pcl/filters/clipper3D.h /usr/include/pcl-1.7/pcl/filters/convolution.h /usr/include/pcl-1.7/pcl/filters/passthrough.h /usr/include/pcl-1.7/pcl/filters/conditional_removal.h /usr/include/pcl-1.7/pcl/filters/impl /usr/include/pcl-1.7/pcl/filters/impl/frustum_culling.hpp /usr/include/pcl-1.7/pcl/filters/impl/conditional_removal.hpp /usr/include/pcl-1.7/pcl/filters/impl/convolution_3d.hpp /usr/include/pcl-1.7/pcl/filters/impl/voxel_grid_covariance.hpp /usr/include/pcl-1.7/pcl/filters/impl/fast_bilateral_omp.hpp /usr/include/pcl-1.7/pcl/filters/impl/project_inliers.hpp /usr/include/pcl-1.7/pcl/filters/impl/morphological_filter.hpp /usr/include/pcl-1.7/pcl/filters/impl/crop_box.hpp /usr/include/pcl-1.7/pcl/filters/impl/covariance_sampling.hpp /usr/include/pcl-1.7/pcl/filters/impl/local_maximum.hpp /usr/include/pcl-1.7/pcl/filters/impl/plane_clipper3D.hpp /usr/include/pcl-1.7/pcl/filters/impl/bilateral.hpp /usr/include/pcl-1.7/pcl/filters/impl/voxel_grid_occlusion_estimation.hpp . How to find out where a program is looking for libraries
The other day I came across a linux command that let me see where a program is expecting to find its libraries. It is very useful to solve library dependency problems for not so popular or proprietary software. I used ldd , it was very informative, but missed one crucial piece of information for me: ldd -v ./my_executable gave good information for libraries that my_executable can link to. But for those it can not link/find, ldd only gave information like:
3 Answers 3
on linux you can use the LD_DEBUG. This link is helpful.
Probably you need the strace command Take a look here http://www.thegeekstuff.com/2011/11/strace-examples/
strace -e open ./my_executable shows pretty much what I want to see. I had the impression that the command I was looking for gives more concise output though. I accept this as the answer anyway.
The information about library paths is stored in /etc/ld.so.conf :
/usr/local/lib64 /usr/local/lib include /etc/ld.so.conf.d/*.conf # /lib64, /lib, /usr/lib64 and /usr/lib gets added # automatically by ldconfig after parsing this file. # So, they do not need to be listed. See man ldconfig for more information.
I am aware of this. However, some programs will look for library from /path/to/installation/dir/libraries . What worse, this path can be hard-coded, and it is different from the actual installation path.
But why should ldd list all directories where it is looking? You can get this info from /etc/ld.so.conf and you can also look if LD_LIBRARY_PATH is set. See this documentation.
How to find location of installed library
Background: I’m trying to build my program but first I need to set up libraries in NetBeans. My project is using GLU and therefore I installed libglu-dev. I didn’t note the location where the libraries were located and now I can’t find them. I’ve switched to Linux just a few days ago and so far I’m very content with it, however I couldn’t google this one out and became frustrated. Is there way to find out where files of package were installed without running the installation again? I mean if I got library xxx and installed it some time ago, is there some-command xxx that will print this info? I’ve already tried locate, find and whereis commands, but either I’m missing something or I just can’t do it correctly. For libglu, locate returns:
/usr/share/bug/libglu1-mesa /usr/share/bug/libglu1-mesa/control /usr/share/bug/libglu1-mesa/script /usr/share/doc/libglu1-mesa /usr/share/doc/libglu1-mesa/changelog.Debian.gz /usr/share/doc/libglu1-mesa/copyright /usr/share/lintian/overrides/libglu1-mesa /var/lib/dpkg/info/libglu1-mesa:i386.list /var/lib/dpkg/info/libglu1-mesa:i386.md5sums /var/lib/dpkg/info/libglu1-mesa:i386.postinst /var/lib/dpkg/info/libglu1-mesa:i386.postrm /var/lib/dpkg/info/libglu1-mesa:i386.shlibs The other two commands fail to find anything. Now locate did its job, but I’m sure none of those paths is where the library actually resides (at least everything I was linking so far was in /usr/lib or /usr/local/lib ). libglu was introduced just as example. I’m looking for a general solution for this problem.
Linux Program can’t find Shared Library at run-time
I’m guessing that this is the part that pulls in the lidid3 library? The file DOES exist, however, what they are looking for is actually a symbolic link to:
I’m wondering if it is an issue with it not being able to follow symbolic links? Perhaps I could manually change it to look for 0.0 if I knew where I was looking to change it. I’m happy to clarify any details. It looks like the includes are done in the following manner:
id3v2: convert.o list.o id3v2.o genre.o $ $ -pedantic -Wall -g -o $@ $^ -lz -lid3 I was able to use Simon’s advice to figure out that there were multiple spots where one might expect a library. I create a symbolic link where the program was linking to the ACTUAL file. Thank you Simon!
Your title asks about the header, but your question’s clearly about the shared library at runtime :-/. You might check if it works if you add the directory containing the symbolic link to your LD_LIBRARY_PATH environment variable.
I clearly don’t understand what I’m doing. I will try to read your statement and see if I can follow your advice.
Did you try running ldconfig as root? This program makes a registry of available libraries used for runtime library loading. The trick is that the library has to be in a place that ldconfig expects to see it, which depends on the distribution. The list of library directories is usually in /etc/ld.so.conf or somewhere similar.
3 Answers 3
Symlinks on libraries work fine, as long as the final target they trace to exists and is accessible.
You have built a dynamically-linked executable, that wishes to be linked against libid3-3.8.so.3 at execution time. This was likely linked during the build phase with something like -L/path/to/libid3/directory -lid3 .
You have a few options to make libid3 available, in generally decreasing order of preference (since you didn’t mention where the file was, I can only be general):
- Create a symlink to libid3* in a directory listed in /etc/ld.so.conf (or /lib or /usr/lib )
- Copy libid3* to a directory listed in /etc/ld.so.conf (or /lib or /usr/lib ) (defaults)
- Add the directory containing libid3* to /etc/ld.so.conf
- Set LD_LIBRARY_PATH=/directory/path/to/libid3* before running your id3v2 executable.
- Recompile id3v2 statically. (It will work, but don’t bother.)
After any of the first 3, rerun ldconfig so the linker cache is updated. (You can then run ldconfig -v to verify it’s resolvable.)
Note those aren’t steps, they’re options. You only need to do 1 of them.
Glad you updated the title. #include directives have nothing to do with linking.