Related
Program is part of the Xenomai test suite, cross-compiled from Linux PC into Linux+Xenomai ARM toolchain.
# echo $LD_LIBRARY_PATH
/lib
# ls /lib
ld-2.3.3.so libdl-2.3.3.so libpthread-0.10.so
ld-linux.so.2 libdl.so.2 libpthread.so.0
libc-2.3.3.so libgcc_s.so libpthread_rt.so
libc.so.6 libgcc_s.so.1 libstdc++.so.6
libcrypt-2.3.3.so libm-2.3.3.so libstdc++.so.6.0.9
libcrypt.so.1 libm.so.6
# ./clocktest
./clocktest: error while loading shared libraries: libpthread_rt.so.1: cannot open shared object file: No such file or directory
Is the .1 at the end part of the filename? What does that mean anyway?
Your library is a dynamic library.
You need to tell the operating system where it can locate it at runtime.
To do so,
we will need to do those easy steps:
Find where the library is placed if you don't know it.
sudo find / -name the_name_of_the_file.so
Check for the existence of the dynamic library path environment variable(LD_LIBRARY_PATH)
echo $LD_LIBRARY_PATH
If there is nothing to be displayed, add a default path value (or not if you wish to)
LD_LIBRARY_PATH=/usr/local/lib
We add the desired path, export it and try the application.
Note that the path should be the directory where the path.so.something is. So if path.so.something is in /my_library/path.so.something, it should be:
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/my_library/
export LD_LIBRARY_PATH
./my_app
Reference to source
Here are a few solutions you can try:
ldconfig
As AbiusX pointed out: If you have just now installed the library, you may simply need to run ldconfig.
sudo ldconfig
ldconfig creates the necessary links and cache to the most recent
shared libraries found in the directories specified on the command
line, in the file /etc/ld.so.conf, and in the trusted directories
(/lib and /usr/lib).
Usually your package manager will take care of this when you install a new library, but not always, and it won't hurt to run ldconfig even if that is not your issue.
Dev package or wrong version
If that doesn't work, I would also check out Paul's suggestion and look for a "-dev" version of the library. Many libraries are split into dev and non-dev packages. You can use this command to look for it:
apt-cache search <libraryname>
This can also help if you simply have the wrong version of the library installed. Some libraries are published in different versions simultaneously, for example, Python.
Library location
If you are sure that the right package is installed, and ldconfig didn't find it, it may just be in a nonstandard directory. By default, ldconfig looks in /lib, /usr/lib, and directories listed in /etc/ld.so.conf and $LD_LIBRARY_PATH. If your library is somewhere else, you can either add the directory on its own line in /etc/ld.so.conf, append the library's path to $LD_LIBRARY_PATH, or move the library into /usr/lib. Then run ldconfig.
To find out where the library is, try this:
sudo find / -iname *libraryname*.so*
(Replace libraryname with the name of your library)
If you go the $LD_LIBRARY_PATH route, you'll want to put that into your ~/.bashrc file so it will run every time you log in:
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/path/to/library
Update
While what I write below is true as a general answer about shared libraries, I think the most frequent cause of these sorts of message is because you've installed a package, but not installed the -dev version of that package.
Well, it's not lying - there is no libpthread_rt.so.1 in that listing. You probably need to re-configure and re-build it so that it depends on the library you have, or install whatever provides libpthread_rt.so.1.
Generally, the numbers after the .so are version numbers, and you'll often find that they are symlinks to each other, so if you have version 1.1 of libfoo.so, you'll have a real file libfoo.so.1.0, and symlinks foo.so and foo.so.1 pointing to the libfoo.so.1.0. And if you install version 1.1 without removing the other one, you'll have a libfoo.so.1.1, and libfoo.so.1 and libfoo.so will now point to the new one, but any code that requires that exact version can use the libfoo.so.1.0 file. Code that just relies on the version 1 API, but doesn't care if it's 1.0 or 1.1 will specify libfoo.so.1. As orip pointed out in the comments, this is explained well at here.
In your case, you might get away with symlinking libpthread_rt.so.1 to libpthread_rt.so. No guarantees that it won't break your code and eat your TV dinners, though.
You need to ensure that you specify the library path during
linking when you compile your .c file:
gcc -I/usr/local/include xxx.c -o xxx -L/usr/local/lib -Wl,-R/usr/local/lib
The -Wl,-R part tells the resulting binary to also look for the library
in /usr/local/lib at runtime before trying to use the one in /usr/lib/.
Try adding LD_LIBRARY_PATH, which indicates search paths, to your ~/.bashrc file
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/path_to_your_library
It works!
The linux.org reference page explains the mechanics, but doesn't explain any of the motivation behind it :-(
For that, see Sun Linker and Libraries Guide
In addition, note that "external versioning" is largely obsolete on Linux, because symbol versioning (a GNU extension) allows you to have multiple incompatible versions of the same function to be present in a single library. This extension allowed glibc to have the same external version: libc.so.6 for the last 10 years.
cd /home/<user_name>/
sudo vi .bash_profile
add these lines at the end
LD_LIBRARY_PATH=/usr/local/lib:<any other paths you want>
export LD_LIBRARY_PATH
Another possible solution depending on your situation.
If you know that libpthread_rt.so.1 is the same as libpthread_rt.so then you can create a symlink by:
ln -s /lib/libpthread_rt.so /lib/libpthread_rt.so.1
Then ls -l /lib should now show the symlink and what it points to.
I had a similar error and it didn't fix with giving LD_LIBRARY_PATH in ~/.bashrc .
What solved my issue is by adding .conf file and loading it.
Go to terminal an be in su.
gedit /etc/ld.so.conf.d/myapp.conf
Add your library path in this file and save.(eg: /usr/local/lib).
You must run the following command to activate path:
ldconfig
Verify Your New Library Path:
ldconfig -v | less
If this shows your library files, then you are good to go.
running:
sudo ldconfig
was enough to fix my issue.
I had this error when running my application with Eclipse CDT on Linux x86.
To fix this:
In Eclipse:
Run as -> Run configurations -> Environment
Set the path
LD_LIBRARY_PATH=/my_lib_directory_path
Wanted to add, if your libraries are in a non standard path, run ldconfig followed by the path.
For instance I had to run:
sudo ldconfig /opt/intel/oneapi/mkl/2021.2.0/lib/intel64
to make R compile against Intel MKL
All I had to do was run:
sudo apt-get install libfontconfig1
I was in the folder located at /usr/lib/x86_64-linux-gnu and it worked perfectly.
Try to install lib32z1:
sudo apt-get install lib32z1
If you are running your application on Microsoft Windows, the path to dynamic libraries (.dll) need to be defined in the PATH environment variable.
If you are running your application on UNIX, the path to your dynamic libraries (.so) need to be defined in the LD_LIBRARY_PATH environment variable.
The error occurs as the system cannot refer to the library file mentioned. Take the following steps:
Running locate libpthread_rt.so.1 will list the path of all the files with that name. Let's suppose a path is /home/user/loc.
Copy the path and run cd home/USERNAME. Replace USERNAME with the name of the current active user with which you want to run the file.
Run vi .bash_profile and at the end of the LD_LIBRARY_PATH parameter, just before ., add the line /lib://home/usr/loc:.. Save the file.
Close terminal and restart the application. It should run.
I got this error and I think its the same reason of yours
error while loading shared libraries: libnw.so: cannot open shared
object file: No such file or directory
Try this. Fix permissions on files:
cd /opt/Popcorn (or wherever it is)
chmod -R 555 * (755 if not ok)
I use Ubuntu 18.04
Installing the corresponding -dev package worked for me,
sudo apt install libgconf2-dev
Before installing the above package, I was getting the below error:
turtl: error while loading shared libraries: libgconf-2.so.4: cannot open shared object file: No such file or directory
I got this error and I think its the same reason of yours
error while loading shared libraries: libnw.so: cannot open shared object
file: No such file or directory
Try this. Fix permissions on files:
sudo su
cd /opt/Popcorn (or wherever it is)
chmod -R 555 * (755 if not ok)
chown -R root:root *
A similar problem can be found here.
I've tried the mentioned solution and it actually works.
The solutions in the previous questions may work. But the following is an easy way to fix it.
It works by reinstalling the package libwbclient
in fedora:
dnf reinstall libwbclient
You can read about libraries here:
https://domiyanyue.medium.com/c-development-tutorial-4-static-and-dynamic-libraries-7b537656163e
I'm trying to build the SDL library from the source code. I've downloaded the compressed file (i.e. SDL2-2.0.3.tar.gz) and extracted it. I don't want to install the files in /usr/local. According to this link, I need to change the configure
The last command says "sudo" so we can write it to /usr/local (by
default). You can change this to a different location with the
--prefix option to the configure script. In fact, there are a LOT of good options you can use with configure! Be sure to check out its
--help option for details.
This is what I've done.
mkdir build
cd build
../configure
make
sudo make install
In install folder that I've created are the following files
share
lib
include
bin
Now I would like to run the test files. I've picked this testatomic.c and this is the command line
gcc testatomic.c -o test -I/home/xxxx/Desktop/SDL2-2.0.3/install/include/SDL2 -L/home/xxxx/Desktop/SDL2-2.0.3/install/lib -lSDL2 -lSDL2main
I get this error
error while loading shared libraries: libSDL2-2.0.so.0: cannot open shared object file: No such file or directory
In lib, these are the files
Where is the shared object file?
You're getting error when running resulting program because system's dynamic linker cannot find required library. Program requires libSDL2-2.0.so.0, linker looks for it in system-defined directories (/lib, /usr/lib, ..., - defined in /etc/ld.so.conf), but finds none - hence an error.
To inform linker where you want it to look for libraries, you can define LD_LIBRARY_PATH environment variable, e.g. in your case:
export LD_LIBRARY_PATH="$HOME/Desktop/SDL2-2.0.3/install/lib"
./test
Other ways is installing libraries in standard location, defining LD_LIBRARY_PATH in your .bashrc (or whatever shell you use), or using rpath, e.g. adding -Wl,-rpath=$HOME/Desktop/SDL2-2.0.3/install/lib at the end of your compilation line.
I was able to fix this problem with:
sudo apt install libsdl2-dev
I too had:
./01_hello_SDL: error while loading shared libraries: libSDL2-2.0.so.0: cannot open shared object file: No such file or directory
as a result of compiling the first C++ program (using the SDL headers) as part of the Lazy Foo tutorial. I found out that libSDL2-2.0.so.0 was just using the find command in the GUI. It turned out to be in /usr/local/lib
Then in terminal I typed:
export LD_LIBRARY_PATH="/usr/local/lib"
I checked the value of LD_LIBRARY_PATH using:
echo $LD_LIBRARY_PATH
I recompiled (don't know if that was necessary) and voila, it worked.
I use gsl.
After I compiled my .cpp file and run it, I faced with below error:
error while loading shared libraries: libgsl.so.0: cannot open shared object file: No such file or directory
I found same as this problem in:
https://groups.google.com/forum/#!topic/cortex_var/6vluX7pP0Sk
&
Linux error while loading shared libraries: cannot open shared object file: No such file or directory
&
http://www.gnu.org/software/gsl/manual/html_node/Shared-Libraries.html
And I have done as in the above links wrote but the error is still remained.
Can anyone help me?
To make it work do the following steps
Start Borne Shell
$LD_LIBRARY_PATH= path to your gsl lib folder inside the gsl installation folder
$export LD_LIBRARY_PATH
now run your executable
It should work fine.
First, you need to locate the file (libgsl.so.0). You can do this, for example, by using the find command:
sudo find / -name "libgsl.so.0"
Let us assume, the file is located in /usr/local/lib.
(If the file has not been found, install the corresponding package or download the source, build it and install it.)
Now, you have two options:
(1) Quick & Dirty:
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib
export LD_LIBRARY_PATH
This adds the path of the library to an environment variable. The disadvantage of this option is, that it is only valid for the current session. It will not work for other users. It will not work once you log off and on again.
(2) Permanent:
Review your /etc/ld.so.conf. If /usr/local/lib is not listed there, add it. Now, run ldconfig to detect the shared object file and add it to some system-wide index.
I got the same error with Krita on Arch Linux. I made a symlink with
ln /usr/lib/libgsl.so /usr/lib/libgsl.so.0
and that fixed it.
In my experience, fastStructure depends on gsl 1.6 but not the latest version.
wget http://gnu.mirror.vexxhost.com/gsl/gsl-1.6.tar.gz
tar -zxvf gsl-1.6.tar.gz
cd gsl-1.16
./configure
make
sudo make install
Add these lines to your .bashrc file on your home directory.
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib
export CFLAGS="-I/usr/local/include"
export LDFLAGS="-L/usr/local/lib"
then, run source ~/.bashrc to set these environment variables.
It works fine when I change the version from the latest to the 1.6.
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/home/shg047/software/gsl/lib/
such as: to-mr: error while loading shared libraries: libgsl.so.19: cannot open shared object file: No such file or directory
Have you tried updating your library? The program I was trying to run simply needed a newer version of gsl (I had 1.9.5 while it needed 2.0.0 or newer).
If you are on arch you can run:
yaourt gsl
and select the appropriate one.
You can use gsl-config --libs in you makefile or in the command line when you link the gsl library. Just type gsl-config you can find the options it offers to you. Choose the options you need, you will find compile and link process much easier than before. As a result, when I type gsl-config --libs in my terminal, I get -L/usr/local/lib -lgsl -lgslcblas -lm. Although it is very simple, first you should know where you gsl is installed. You can add the directory to the PATH environment variable or use the absolute path to execute gsl-config .
I needed libgsl.so.19:
/snap/inkscape/current/bin/inkscape: error while loading shared libraries: libgsl.so.19: cannot open shared object file: No such file or directory
I solved it with:
Installing Anaconda
searched for libgsl.so.19 and found it in ~/anaconda3/lib
run LD_LIBRARY_PATH=$LD_LIBRARY_PATH:~/anaconda3/lib (best add it to ~/.basrc)
I'm have built and installed Cyassl-2.4.2 on my unix machine to use with a project of mine; however, when I try to compile my c project, the compiler cannot find the libcyassl.a file. I have searched many times in the Cyassl.2.4.2 folder and am unable to find the file myself. Where is this file locate? Have I missed a step in bulding/installing Cyassl.2.4.2? Thanks!
I had successfully built and installed CyaSSL 2.4.2 here and this is what I got:
~/cyassl$ find . -iname "*.a"
./src/.libs/libcyassl.a
~/cyassl$ ls /usr/local/lib/
libcyassl.a libcyassl.la libcyassl.so libcyassl.so.3 libcyassl.so.3.0.3
The building process used was:
./autogen.sh
./configure
make
sudo make install
The installation prints out:
Libraries have been installed in:
/usr/local/lib
If you ever happen to want to link against installed libraries
in a given directory, LIBDIR, you must either use libtool, and
specify the full pathname of the library, or use the -LLIBDIR'
flag during linking and do at least one of the following:
- add LIBDIR to theLD_LIBRARY_PATH' environment variable
during execution
- add LIBDIR to the LD_RUN_PATH' environment variable
during linking
- use the-Wl,-rpath -Wl,LIBDIR' linker flag
- have your system administrator add LIBDIR to `/etc/ld.so.conf'
See any operating system documentation about shared libraries for
more information, such as the ld(1) and ld.so(8) manual pages.
I'm trying to get my Cuda SDK samples running, but I get the following error:
./bandwidthTest: error while loading shared libraries:
libcudart.so.4: cannot open shared object file:
No such file or directory
Why can I compile the example successfully, but not run it? Is there a way to specify the path to the CUDA runtime library manually?
try:
32-bit: sudo ldconfig /usr/local/cuda/lib
64-bit: sudo ldconfig /usr/local/cuda/lib64
cheers
First these that you need is to concatenate the paths to the CUDA binaries and libraries. This is simply done by adding the following lines to your .bashrc file.
export PATH=$PATH:/usr/local/cuda/bin
export LD_LIBRARY_PATH=:/usr/local/cuda/lib64
If you are using a 32-bit operating system change lib64 to lib
Second, there should have been some shared object files installed in /usr/lib or /usr/lib64, depending on your operating system. These object files should be contained in a directory called "nvidia". The two files we are concerned with are names libcuda.so.drivernumber and libOpenCL.so.somenumber. To differentiate between the actual shared object files just use ls -l. The symbolic links will show what they are actually linking to.
As root, execute the following commands:
ln -s /usr/lib64/nvidia/libcuda.so.somenumber /usr/lib64/libcuda.so
ln -s /usr/lib64/nvidia/libOpenCL.so.somenumber /usr/lib64/libOpenCL.so
That should allow you to compile all the sources in the SDK.
As of Cuda 5.5 and Ubuntu 12.04/12.10, the command above becomes (notice the Ubuntu and Cuda directory changes) for 64bit
ln -s /usr/local/cuda/lib64/libcuda.so.5.5 /usr/lib/libcuda.so.5.5
That is, the lib folders on Ubuntu as of 12.04 are lib32 and lib; the 64 is implicit, and cuda 5.5 and greater now installs to a different directory.
1 error while loading shared libraries: libcudart.so.6.0: cannot open shared object file: No such file or directory
32-bit: sudo ldconfig /usr/local/cuda/lib
64-bit: sudo ldconfig /usr/local/cuda/lib64
(refer: http://blog.csdn.net/shenchong721/article/details/21529295)
Works for me!
LD_LIBRARY_PATH is strongly deprecated. It may mess up other programs, and others may reset it. It should only be used to temporarily override the permanent paths for testing purposes (don't take my word, google it).
Instead, add a line with your cuda lib directory on it to /etc/ld.so.conf, after any existing lines.
For example, if you installed on /usr/local/cuda, you will need to add
32-bit : /usr/local/cuda/lib
64-bit : /usr/local/cuda/lib64
Save, and run ldconfig. This should permanently fix the problem.
The symbolic links are probably already set up by the installation. If not, then add them as Alex advised.
Note - I received errors referencing /lib, but I needed to add lib64 to fix them.
create a nvidia_settings.conf file in /etc/ld.so.conf.d/ and add the path to the libs in the file nvidia_settings.conf
/usr/local/cuda/lib64
/usr/local/cuda/lib
Now to update the changes run the following command:
sudo ldconfig
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/cuda/lib
or if you are running cuda-5.0 on a 64-bit machine
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/cuda-5.0/lib64
the system find library with ld tool. as the top answer says, 64-bit: sudo ldconfig /usr/local/cuda-xx/lib64 ;;xx is the cuda libraryedition
In my case I was running an application using MPI. The error was:
libcudart.so.7: cannot open shared object file
CUDA was properly installed in all nodes. Also, as in the previous answers, the variables $PATH and $LD_LIBRARY_PATH were pointing to the binary and libraries respectively.
Passing the $PATH and $LD_LIBRARY_PATH in the MPI command solved the issue.
mpirun -x PATH=$PATH -x LD_LIBRARY_PATH=$LD_LIBRARY_PATH ...