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.
shared library not found during compilation
So I got several shared libraries that I am trying to permanently install on my Ubuntu system but I am having some difficulty with it. I want to install the libraries and the headers in a separate folder under /usr/local/lib and /usr/local/include (for example a folder named agony ) so it would be clean and removing them would just require that I delete those folders. so it looks something like this:
/usr/local/lib/agony/libbtiGPIO.so /usr/local/lib/agony/libbtiDSP.so . /usr/local/include/agony/GPIO.h /usr/local/include/agony/DSP.h . And I added a file here /etc/ld.so.conf.d/agony.conf which include a line describing the path to the library folder:
$ cat /etc/ld.so.conf.d/agony.conf /usr/local/lib/agony and I perform sudo ldconfig to update the library database. So to double check if the library is found I do ldconfig -p | grep bti* and I see the following result:
$ ldconfig -p | grep bti . libbtiGPIO.so (libc6,x86-64) => /usr/local/lib/agony/libbtiGPIO.so libbtiDSP.so (libc6,x86-64) => /usr/local/lib/agony/libbtiDSP.so . At this point I should be able to use the libraries without specifying the library path. But When I attempt to compile an application without providing the library path (-L) it fails. However, when I supply gcc with the library path ex:
gcc source.c -L /usr/local/lib/agony output -lbtiGPIO -lbtiDSP it works!! I don’t want to use LD_LIBRARY_PATH environment variable because this library is going to be used everywhere on the system and I don’t want other compilers to worry about providing LD_LIBRARY_PATH . What am I doing wrong here?
2 Answers 2
At this point I should be able to use the libraries without specifying the library path
You have built your shared library libbtiGPIO.so (just sticking with that one), placed it in /usr/local/lib/agony , and updated the ldconfig database accordingly.
The effect of that is when you run a program that has been linked with libbtiGPIO then the dynamic linker ( /lib/x86_64-linux-gnu/ld-2.21.so , or similar) will know where to look to load that library into the process and you will not need to tell it by setting an LD_LIBRARY_PATH in the environment.
However, you haven’t done anything that affects the list of default library search directories that are hardwired into your build of gcc , that it passes to the linker ( /usr/bin/ld ) when you link a program with libbtiGPIO in the first place.
That list of default search directories is what you will find if your do a verbose build of your program — gcc -v . — and then pick out the value of LIBRARY_PATH from the output, e.g.
LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/5/:\ /usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/:\ /usr/lib/gcc/x86_64-linux-gnu/5/../../../../lib/:\ /lib/x86_64-linux-gnu/:\ /lib/../lib/:\ /usr/lib/x86_64-linux-gnu/:\ /usr/lib/../lib/:\ /usr/lib/gcc/x86_64-linux-gnu/5/../../../:\ /lib/:\ /usr/lib /usr/local/lib/agony is not one of those and to make it one of those you would have to build gcc from source yourself. Hence, in order to link your program with libbtiGPIO you still need to tell ld where to find it with -L/usr/local/lib/agony -lbtiGPIO .
Where does Ubuntu look for shared libraries?
When I run a process that links to a shared library at runtime (linked when the process starts, not linked later with dlload() ), where does it look for that shared library ( .so ) file other than LD_LIBRARY_PATH ? Background: I have some C++ code that I wrote that uses a particular third-party library. I have installed the library and compiled my code on two different platforms, both Ubuntu but different versions, and different versions of gcc as well. The library was compiled and installed from source, and is located in /usr/local/lib on both platforms. When I compile my code, I link with the pkg-config —libs parameters for the third-party library and I’ve verified that pkg-config —libs returns the exact same thing on both platforms. My code compiles successfully on both platforms, and LD_LIBRARY_PATH is not defined (or defined as empty: «» ) on both platforms. However, when I run it on one platoform it works fine, and on the other I get this error:
error while loading shared libraries: libthrift-0.9.0.so: cannot open shared object file: No such file or directory Funnily enough, the ones that doesn’t work is the newer version of Ubuntu and gcc. :/ So I’m trying to figure out how the working one is able to locate the library, so that I can make the broken one locate the library in the same way. (i.e., without setting LD_LIBRARY_PATH ) Update: Here’s my output from cat /etc/ld.so.conf.d/* . on the working (older) system:
/usr/lib/mesa /usr/lib32/mesa /usr/lib/alsa-lib # libc default configuration /usr/local/lib # Multiarch support /lib/x86_64-linux-gnu /usr/lib/x86_64-linux-gnu # libc default configuration /usr/local/lib # Multiarch support /lib/x86_64-linux-gnu /usr/lib/x86_64-linux-gnu /usr/lib/x86_64-linux-gnu/mesa 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.