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.
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.
The program fails to find a shared library even with the path of the library included in $LD_LIBRARY_PATH (also exported correctly). However, after I add the path to /etc/ld.so.conf and then execute ldconfig, the program runs without error.
Why does this happen?
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
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!
On a Linux system, I am trying to run a Fortran program that makes use of some shared libraries (netCDF libs, if that makes a difference). Before I run, I set LD_LIBRARY_PATH so that it points to the location of my libraries. Then I run the executable and I quickly get the error
../my_program: error while loading shared libraries: libnetcdff.so.5: cannot open shared object file: No such file or directory
Now, I double check the value of LD_LIBRARY_PATH, and then cd to it and find plain as day
$ ls *ff*
$ libnetcdff.a libnetcdff.la libnetcdff.so libnetcdff.so.0 libnetcdff.so.0.0.0
So the libnetcdff is absolutely present.
Could anyone point me to the problem?
The one thing that has occurred to me is that the executable seems to want to find libnetcdff.so.5, while the library that is present is actually libnetcdff.so.0. Is that the problem? If so, is there a way to convince the executable to not insist on "5"? Alternatively, would a link from libnetcdff.so.0 to libnetcdff.so.5 solve the problem? (I don't have permissions in the directory, BTW, which is why I haven't tried that yet.)
Environment info: CentOS machine, code compiled with gfortran. And yes, when I compiled, my -L flags were pointing to the same directory that LD_LIBRARY_PATH points to.
Thanks.
A library link should work. Since you mention that you do not have root/sudo access, what you can do is link in a file you do have access in:
ln -s /path/to/libnetcdff.so.0 /path/you/have/access/to/libnetcdff.so.5
And then add in the /path/you/have/access/to/ in your LD_LIBRARY_PATH.