I am using clang-9 with mysql-connector-c++8.
After mysql-connector-c++ upgrade from 1.1.12 to 8.x and running function in my app: get_driver_instance() an exception is being thrown:
"Couldn't load library libmysqlclient_r.so: libmysqlclient_r.so: cannot open shared object file"
What I've tried so far:
ldd on my newly compiled binary, but my newly compiled binary does not link against libmysqlclient_r.so.
strace -f my binary, but no info about loading this library
removed /etc/ld.so.cache and rebuilt it with ldconfig, than recompiled my software
updatedb && locate \*\.so | xargs ldd and the same for \*\.so\.\*, but no file is showing it is linked with libmysqlclient_r.so
There are no errors during compilation. I've got out of ideas what might be wrong. What might I do to diagnose it further?
Runtime dlopen calls will not produce any output in ldd, but you can convince ld.so to print when a library is loaded by whom by setting the environment variable LD_DEBUG=files.
Related
I tried to run a program that requires log4cpp,
I got following error when I try to run the program
error while loading shared libraries: liblog4cpp.so.4: cannot open shared object file: No such file or directory
I have set the library path in $LD_LIBRARY_PATH and these are the files in my /usr/local/lib directory:
liblog4cpp.a
liblog4cpp.so
liblog4cpp.so.5.0.6
liblog4cpp.la
liblog4cpp.so.5
pkgconfig
What could be the problem here ?
Thanks!
Use
ldd [program name]
so see what's actually loaded (assuming you are on a Unix system since you use LD_LIBRARY_PATH).
I am trying to write a simple application with GLFW on Linux. Right now the main file (the only file) is basically just a few lines of code to make sure the dynamic library linked correctly. Here it is:
#include <GLFW/glfw3.h>
#include <iostream>
int main()
{
glfwInit();
std::cout << "It works this far!" << std::endl;
glfwTerminate();
}
The include files are stored in a directory labelled "include" and the library files are stored in a directory labelled "lib". As of right now, I am compiling the program with the following line:
g++ -Wl,-Rlib -Iinclude -Llib test.cpp -o test -lglfw.3.2
It compiles and links just fine, but when I try to execute it, I get the following error:
./test: error while loading shared libraries: libglfw.so.3: cannot open shared object file: No such file or directory
Now, before you rush to downvote this question into oblivion and mark it as a duplicate, at least allow me to explain why I believe my question is different enough to not be a duplicate. I already attempted the solutions that the other questions presented, but it was unsuccessful. As you can see, I tried setting the path to the library during linking with the -Wl,-Rlib tag. I also tried setting LD_LIBRARY_PATH to point to the location of my libraries (the 'lib' folder), but it still threw the same error. (It didn't matter if the path was relative or absolute.)
So, the next thing I tried was running the ldd command on the executable. I got some other dependencies that were working just fine, but importantly, I got this:
libglfw.so.3 => not found
For some reason, it insists on looking for libglfw.so.3. It will not have it any other way. Upon renaming the library from libglfw.3.2.so to libglfw.so.3, the program executed just fine and printed It works this far! as if there were no problems at all.
Why would this happen?
For some reason, it insists on looking for libglfw.so.3. ... Upon renaming the library from libglfw.3.2.so to libglfw.so.3 ...
The ELF executables contain the exact name of the dynamic libraries used.
If the executable contains the library name "libglfw.so.3" the file must be named exactly like this.
The file naming scheme is intentionally done in a way that not the "full" version is coded into the file name: This way a later version ("libglfw.so.3.15") will work with the executable.
Normally there should be a symbolic link to the latest version of the library installed:
libglfw.so.3 -> libglfw.so.3.2
This symbolic link seems to be missing on your computer. I would say that this is an installation problem!
EDIT
The question could be: Why is the file name stored in the executable file not libglfw.3.2.so but libglfw.so.3?
The answer has to do with the backward compatibility when a new version of a library is installed:
Normally you would use the switch -lglfw and a symbolic link named libglfw.so is looked up.
If you stored the file name libglfw.so in the executable file and a new, incompatible version if this library (libglfw.so.4) is installed you would have no chance to get the program running by having both versions of the library installed.
To enable backward compatibility by having both versions of the library installed the "real" symbolic link name of the library (libglfw.so.3) must be stored in the executable file.
Therefore the "expected" file name of a library is stored in the library itself: Inside the file libglfw.so.3.2 you'll find some information that the file expects itself to be stored as libglfw.so.3.
The linker will use this information about the file name because it assumes that the library name given in the linker switch (-lglfw) is less "precise" than the name stored in the library itself.
For some reason, it insists on looking for libglfw.so.3. It will not have it any other way.
This is the Linux convention for shared libraries which is described here among other places. For Linux libfoo.so.x.y.z is considered to have the same ABI as libfoo.so.x. Usually when shared libraries are installed (e.g. via rpm, dpkg, etc.) there's an invocation of ldconfig that happens so that the just installed libraries have a symlink following the convention installed that references the library. Also these libs (if installed to a "trusted location"), are added to a linker cache for performance reasons.
It compiles and links just fine, but when I try to execute it, I get the following error:
./test: error while loading shared libraries: libglfw.so.3: cannot open shared object file: No such file or directory
libglfw.so.3 isn't on ld-linux.so's path.
As you can see, I tried setting the path to the library during linking with the -Wl,-Rlib
Still won't find it -- libglfw.so.3 isn't on ld-linux.so's path. You can add it by doing something like:
ldconfig -n /path/to/lib
Which should output the requisite libglfw.so.3 symlink for your lib.
IIRC setting the rpath might require a full path.
I also tried setting LD_LIBRARY_PATH to point to the location of my libraries
Again, libglfw.so.3 isn't on ld-linux.so's path.
I'm having trouble finding why this library (matio) isn't working for me. In my Makefile I have this:
LIBS += -L/home/brian/.../matio-1.5.6/src/.libs/ -lmatio
When I attempt to run my code (links fine) I get this error:
error while loading shared libraries: libmatio.so.4: cannot open shared object file: No such file or directory
libmatio.so.4 exists in the directory specified by the -L flag.
I built the library and it seems to go through make check with only a handful writing errors (which is fine as I only need it for reading).
Things I've tried:
Specifying the name (i.e. -l:libmatio.so.4.0.2)
Adding the path to LD_LIBRARY_PATH
Adding the path as a line in /etc/ld.so.conf and run sudo ldconfig
Adding a new file in /etc/ld.so.conf.d with the path and run sudo ldconfig
(When I run ldconfig -p | grep matio nothing returns. Am I doing something wrong with ldconfig?)
The error is actually telling you "no compatible library with that name exists in the library cache", not "no file with that filename exists on disk".
So, confusingly, this can happen when the shared object file is in the wrong format.
Ensure that it was built for the right platform by the right compiler! You can have a look with file and verify that the dynamic link is failing using ldd on your executable.
In Ubuntu 14.04, I have downloaded some source code which comes with a makefile. I have then run "make" on it to compile, which builds an executable. When executing this file, I receive the following error:
./mt_test: error while loading shared libraries: libcudart.so.7.0: cannot open shared object file: No such file or directory
Now, the file libcudart.so.7.0 is located in the directory /usr/local/cuda-7.0/lib64. But in my .bashrc file, I have the line: export LD_LIBRARY_PATH=/usr/local/cuda-7.0/lib64:$LD_LIBRARY_PATH. Furthermore, if I run echo $LD_LIBRARY_PATH from the terminal, one of the entries is this path. There are no other copies of libcudart.so.7.0 elsewhere on my system.
Is there any reason why the executable might not be able find this library, even though its directory is one of the search directories?
Strangely, this error has only happened since installing Matlab on my system. There is now a file called libcudart.so.6.5 located at /usr/local/MATLAB/R2015a/bin/glnxa64, but this path is not part of LD_LIBRARY_PATH.
As MadScientist probably correctly guessed, this is likely a 32 vs. 64-bit mismatch. Run the following command:
file -L ./mt_test /usr/local/cuda-7.0/lib64/libcudart.so.7.0
The command should report either ELF 32-bit LSB ..., or ELF 64-bit LSB ... for both files. If one of the files is 32-bit, and the other 64-bit, then they are not compatible.
You can gain further insight into where the dynamic linker is searching for libcudart.so.7.0 by running the following command:
LD_DEBUG=files,libs ./mt_test
I'm a little confused as to what's happening here, when I'm our shared computer I can run our program, but when I ssh in from my house to restart it I get an exception
$ ./jsonparser
./jsonparser: error while loading shared libraries: libjansson.so.4: cannot open shared object file: No such file or directory
Is there some other way I should launch the app?
libjansson is installed to /usr/local/lib:
$ ls /usr/local/lib
libjansson.a libjansson.la libjansson.so libjansson.so.4 libjansson.so.4.6.0
Maybe /usr/local/lib is not in your Library pathg ( LD_LIBRARY_PATH I guess )? Or maybe there is a dependency for libjansson.so.4 is not resolved? By using ldd ./jsonparser ldd tries to load all dependent .so-file. Hopefully this will give you some more information about your issue.