I am using a tool that repeatedly returns an error saying that it cannot load a library file (libppl.so.12: cannot open shared object file: No such file or directory) at <path_to_file>. The thing is that the required file is actually there.
I've tried setting the LD_LIBRARY_PATH, adding entries to ld.so.conf and ld.so.conf.d and then running ldconfig, which are solutions I found on the links provided bellow. The problem, however, is still there. When running ldconfig -v, I can see that it looks at the file directory but does not populate the cache for any of the so files in the directory, including the one at <path_to_file>.
What could be the problem?
useful links:
cannot open shared object file: No such file or directory
Linux error while loading shared libraries: cannot open shared object file: No such file or directory
The tool may be 32 bits and you've the 64 bits version of the library.
You can check the binary architecture via the file command.
Also, you can force the library via LD_PRELOAD
Related
After RHEL6-7 migration setting up oracle jws web servers says "error while loading shared libraries: libpcre.so.0: cannot open shared object file: No such file or directory "
/apps/oracle/jws-webserver-3.0.3/jws_proxy/httpd/sbin/httpd: error while loading shared libraries: libpcre.so.0: cannot open shared object file: No such file or directory
Well, it looks like your migration messed up a couple of things.
Check if you actually have or not the library.
find / -name libpcre.so.1
If you do, then check your LD_LIBRARY_PATH, if not, then add the path to it so the binary can get it.
Another option is, pcre is not even installed, then process to get it and install it.
I have used ctags command to generate tags to traverse in vi editor. Unfortunately
a shared library is not available. how to fix this problem, i don't want to install the library as i'm working on a shared development environment.
Please check the below error.
ctags: error while loading shared libraries: libgpm.so.1: cannot open shared object file: No such file or directory.
Use export LD_LIBRARY_PATH=/path/where/libgpm.so/is/located
And then start it again.
I have a compiled script (it's some utility) and the source code of which is unavailable. As soon as I run the script this error shows up:
error while loading shared libraries: librun.so: cannot open shared object file: No such file or directory
I have faced these kind of errors in past which had different solutions. I tried all as per my knowledge and..
librun.so is there in lib folder of my application
It is symbolic link and pointing to correct version
librun.so is available in path variable
changed .profile to look for the required library
changed permissions and checked
"which librun.so" is also returning the presence of that library
still this error shows up.
What can be the reason for this problem?
The dynamic linker is unable to find librun.so during runtime linking of shared libraries. Try adding the path of directory containing librun.so to the LD_LIBRARY_PATH environment variable when starting the application script.
I am trying to make a Qt5 part of my source tree, so I haven't installed it on my machine, just copied it from source control. I am having a problem when I try to run uic.exe:
stiopa#stiopa-VirtualBox:~/ct/LinuxLibs/Qt/bin > ./uic
./uic: error while loading shared libraries: libQt5Core.so.5: cannot open shared object file: No such file or directory
I am still getting the same error even when I copy the libQt5Core library to bin directory. How is uic looking for shared libraries? Is there any environment variable I need to set to fix it?
This is yet another case of not putting the dependent shared libraries in a defined location that is supported by the program.
If you're planning on doing the 'copy the files to the same directory as the executable', the fast solution is to reference the directory in the library load path; e.g. if the binary is in $HOME/foo, you do:
export LD_LIBRARY_PATH=${LD_LIBRARY_PATH}${LD_LIBRARY_PATH:+:}$HOME/foo
This adds or makes $HOME/foo the run-time-linker's load path. As a result, any programs you run will look in this directory for libraries, as well as the default set for the OS (defined by the ld.so configuration), as well as the paths that are defined within the application itself (the rpath).
If you're going to follow this route, what you can do is to move the binary to target.bin, create a target bash script, which invokes the bin file automatically; e.g.
#!/bin/bash -p
export LD_LIBRARY_PATH=${LD_LIBRARY_PATH}${LD_LIBRARY_PATH:+:}$(dirname $0)
exec $0.bin "$*"
A secondary mechanism which will permit you to change the search location for a binary; without requiring an environment variable insert is to modify the binary so that it searches in different locations than it usually does; this takes advantage of some features in the run-time linker (which looks for libraries).
There is a program called chrpath, which can be added by various package managers, which allows you to edit the rpath directly. In this case; you can change the additional search path of the binary using:
chrpath -r '$ORIGIN' foo
This means that the program will look in the same directory as the binary for .so files, thus allowing it to run.
I have written a small HTTPServer application using Poco and I get the following error during runtime:
factoryProject> ./httpServer ./httpServer: error while loading shared
libraries: libPocoNet.so.16: cannot open shared object file: No such
file or directory
My libraries successfully linked during compilation because they were located in a specific directory that I pointed to in my make file using a -L/some/path.
I have read up on the ldconfig command and it stated that it usually looks for libraries in /usr/lib, but I do not have admin privee to add the Poco libraries into that directory.
How do I point to that a custom library directory so that ld will load it during runtime?
I have looked into a few possible solutions with the most popular being to add a config file for ldconfig to pickup, but this solution seems complicated and I do not want to add a config file to this common server.
The solution that was the simplest for me was to update the following environment variable:
echo $LD_LIBRARY_PATH
The LD_LIBRARY_PATH environment variable can list directories where libraries are searched for first during runtime and after setenv command I have a working HTTP server!