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
This is the command I am running to install Debian packages from the virtual repo I have created. This repo has library A that contains a shared library and library B that starts the executable that uses this shared library in postinst section of Debian. Library B depends on Library A ( via control file of Debian ). Both A and B libraries were packaged by me.
apt-get -o Dir::Etc::SourceList="${VIRTUAL_REPO_PATH}/upgrade.list" -o Debug::pkgProblemResolver=yes -o Dir::Etc::SourceParts="/dev/null" -o Dir::State::Lists="${VIRTUAL_REPO_PATH}/lists" -o Dpkg::Options::="--force-confdef" -o Dpkg::Options::="--force-confold" install ${VIRTUAL_REPO_PATH}/${COMPONENT_DEB}*.deb -y --allow-unauthenticated
I have added triggers file to Debian of library A with "activate-noawait ldconfig" row as mentioned here.
The Debian of library A has 3 files ( extracted with dpkg-deb --control .. ): control, postinst, triggers.
postinst
#! /bin/sh
set -e
if [ "$1" = "configure" ]; then
ldconfig
fi
triggers
activate-noawait ldconfig
In dpkg.log I can see that library A was installed and configured before library B.
2021-04-16 08:54:16 configure libsigar:amd64 1.7.0-fs1 <none>
2021-04-16 08:54:16 status unpacked libsigar:amd64 1.7.0-fs1
2021-04-16 08:54:16 status half-configured libsigar:amd64 1.7.0-fs1
2021-04-16 08:54:16 status installed libsigar:amd64 1.7.0-fs1
In postinst of the library B I am starting the executable and at that given moment of time it fails with error while loading shared libraries: A: cannot open shared object file: No such file or directory. If I start the executable immediately after the installation everything works just fine. I tried to comment out the postinst script starting from the moment executable is started and execute that part manually - no issue whatsoever.
Also I have added ldconfig call to postinst just before the executable is started with no luck.
Does anyone know what is the reason?
I found the root cause. It appears I have to create a symlink (libsigar.so.0 -> libsigar.so) in the package before postinst is called. Otherwise even ldconfig isn't sufficient enough.
The run-time library package should include the symbolic link for the
SONAME that ldconfig would create for the shared libraries. For
example, the libgdbm3 package should include a symbolic link from
/usr/lib/libgdbm.so.3 to libgdbm.so.3.0.0. This is needed so that the
dynamic linker (for example ld.so or ld-linux.so.*) can find the
library between the time that dpkg installs it and the time that
ldconfig is run in the postinst script.[59]
http://www.chiark.greenend.org.uk/doc/debian-policy/policy.html/ch-sharedlibs.html
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'm trying to compile a .cpp file but I must install libssh2. I have downloaded the package from libssh2.org and when I enter: ./buildconf I'm getting:
Neither libtoolize nor glibtoolize could be found!
I don't know what to do, I have included in the header libssh2.h ( #include ) and also the file does exists in the same folder where I have the source file what I'm trying to compile.
It is provided by the package libtool.
On Ubuntu you'd simply
sudo apt-get install libtool
see also http://manpages.ubuntu.com/manpages/dapper/man1/libtoolize.1.html
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 ...