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 trying to compile my program and it returns this error :
usr/bin/ld: cannot find -l<nameOfTheLibrary>
in my makefile I use the command g++ and link to my library which is a symbolic link to my library located on an other directory.
Is there an option to add to make it work please?
To figure out what the linker is looking for, run it in verbose mode.
For example, I encountered this issue while trying to compile MySQL with ZLIB support. I was receiving an error like this during compilation:
/usr/bin/ld: cannot find -lzlib
I did some Googl'ing and kept coming across different issues of the same kind where people would say to make sure the .so file actually exists and if it doesn't, then create a symlink to the versioned file, for example, zlib.so.1.2.8. But, when I checked, zlib.so DID exist. So, I thought, surely that couldn't be the problem.
I came across another post on the Internets that suggested to run make with LD_DEBUG=all:
LD_DEBUG=all make
Although I got a TON of debugging output, it wasn't actually helpful. It added more confusion than anything else. So, I was about to give up.
Then, I had an epiphany. I thought to actually check the help text for the ld command:
ld --help
From that, I figured out how to run ld in verbose mode (imagine that):
ld -lzlib --verbose
This is the output I got:
==================================================
attempt to open /usr/x86_64-linux-gnu/lib64/libzlib.so failed
attempt to open /usr/x86_64-linux-gnu/lib64/libzlib.a failed
attempt to open /usr/local/lib64/libzlib.so failed
attempt to open /usr/local/lib64/libzlib.a failed
attempt to open /lib64/libzlib.so failed
attempt to open /lib64/libzlib.a failed
attempt to open /usr/lib64/libzlib.so failed
attempt to open /usr/lib64/libzlib.a failed
attempt to open /usr/x86_64-linux-gnu/lib/libzlib.so failed
attempt to open /usr/x86_64-linux-gnu/lib/libzlib.a failed
attempt to open /usr/local/lib/libzlib.so failed
attempt to open /usr/local/lib/libzlib.a failed
attempt to open /lib/libzlib.so failed
attempt to open /lib/libzlib.a failed
attempt to open /usr/lib/libzlib.so failed
attempt to open /usr/lib/libzlib.a failed
/usr/bin/ld.bfd.real: cannot find -lzlib
Ding, ding, ding...
So, to finally fix it so I could compile MySQL with my own version of ZLIB (rather than the bundled version):
sudo ln -s /usr/lib/libz.so.1.2.8 /usr/lib/libzlib.so
Voila!
If your library name is say libxyz.so and it is located on path say:
/home/user/myDir
then to link it to your program:
g++ -L/home/user/myDir -lxyz myprog.cpp -o myprog
There does not seem to be any answer which addresses the very common beginner problem of failing to install the required library in the first place.
On Debianish platforms, if libfoo is missing, you can frequently install it with something like
apt-get install libfoo-dev
The -dev version of the package is required for development work, even trivial development work such as compiling source code to link to the library.
The package name will sometimes require some decorations (libfoo0-dev? foo-dev without the lib prefix? etc), or you can simply use your distro's package search to find out precisely which packages provide a particular file.
(If there is more than one, you will need to find out what their differences are. Picking the coolest or the most popular is a common shortcut, but not an acceptable procedure for any serious development work.)
For other architectures (most notably RPM) similar procedures apply, though the details will be different.
Compile Time
When g++ says cannot find -l<nameOfTheLibrary>, it means that g++ looked for the file lib{nameOfTheLibrary}.so, but it couldn't find it in the shared library search path, which by default points to /usr/lib and /usr/local/lib and somewhere else maybe.
To resolve this problem, you should either provide the library file (lib{nameOfTheLibrary}.so) in those search paths or use -L command option. -L{path} tells the g++ (actually ld) to find library files in path {path} in addition to default paths.
Example: Assuming you have a library at /home/taylor/libswift.so, and you want to link your app to this library. In this case you should supply the g++ with the following options:
g++ main.cpp -o main -L/home/taylor -lswift
Note 1: -l option gets the library name without lib and .so at its beginning and end.
Note 2: In some cases, the library file name is followed by its version, for instance libswift.so.1.2. In these cases, g++ also cannot find the library file. A simple workaround to fix this is creating a symbolic link to libswift.so.1.2 called libswift.so.
Runtime
When you link your app to a shared library, it's required that library stays available whenever you run the app. In runtime your app (actually dynamic linker) looks for its libraries in LD_LIBRARY_PATH. It's an environment variable which stores a list of paths.
Example: In case of our libswift.so example, dynamic linker cannot find libswift.so in LD_LIBRARY_PATH (which points to default search paths). To fix the problem you should append that variable with the path libswift.so is in.
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/home/taylor
During compilation with g++ via make define LIBRARY_PATH if it may not be appropriate to change the Makefile with the -Loption. I had put my extra library in /opt/lib so I did:
$ export LIBRARY_PATH=/opt/lib/
and then ran make for successful compilation and linking.
To run the program with a shared library define:
$ export LD_LIBRARY_PATH=/opt/lib/
before executing the program.
First, you need to know the naming rule of lxxx:
/usr/bin/ld: cannot find -lc
/usr/bin/ld: cannot find -lltdl
/usr/bin/ld: cannot find -lXtst
lc means libc.so, lltdl means libltdl.so, lXtst means libXts.so.
So, it is lib + lib-name + .so
Once we know the name, we can use locate to find the path of this lxxx.so file.
$ locate libiconv.so
/home/user/anaconda3/lib/libiconv.so # <-- right here
/home/user/anaconda3/lib/libiconv.so.2
/home/user/anaconda3/lib/libiconv.so.2.5.1
/home/user/anaconda3/lib/preloadable_libiconv.so
/home/user/anaconda3/pkgs/libiconv-1.14-0/lib/libiconv.so
/home/user/anaconda3/pkgs/libiconv-1.14-0/lib/libiconv.so.2
/home/user/anaconda3/pkgs/libiconv-1.14-0/lib/libiconv.so.2.5.1
/home/user/anaconda3/pkgs/libiconv-1.14-0/lib/preloadable_libiconv.so
If you cannot find it, you need to install it by yum (I use CentOS). Usually you have this file, but it does not link to right place.
Link it to the right place, usually it is /lib64 or /usr/lib64
$ sudo ln -s /home/user/anaconda3/lib/libiconv.so /usr/lib64/
Done!
ref: https://i-pogo.blogspot.jp/2010/01/usrbinld-cannot-find-lxxx.html
When you compile your program you must supply the path to the library; in g++ use the -L option:
g++ myprogram.cc -o myprogram -lmylib -L/path/foo/bar
I had this problem with compiling LXC on a fresh VM with Centos 7.8. I tried all the above and failed. Some suggested removing the -static flag from the compiler configuration but I didn't want to change anything.
The only thing that helped was to install glibc-static and retry. Hope that helps someone.
Check the location of your library, for example lxxx.so:
locate lxxx.so
If it is not in the /usr/lib folder, type this:
sudo cp yourpath/lxxx.so /usr/lib
Done.
Apart from the answers already given, it may also be the case that the *.so file exists but is not named properly. Or it may be the case that *.so file exists but it is owned by another user / root.
Issue 1: Improper name
If you are linking the file as -l<nameOfLibrary>
then library file name MUST be of the form lib<nameOfLibrary>
If you only have <nameOfLibrary>.so file, rename it!
Issue 2: Wrong owner
To verify that this is not the problem - do
ls -l /path/to/.so/file
If the file is owned by root or another user, you need to do
sudo chown yourUserName:yourUserName /path/to/.so/file
Here is Ubuntu information of my laptop.
lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 18.04.2 LTS
Release: 18.04
Codename: bionic
I use locate to find the .so files for boost_filesystem and boost_system
locate libboost_filesystem
locate libboost_system
Then link .so files to /usr/lib and rename to .so
sudo ln -s /usr/lib/x86_64-linux-gnu/libboost_filesystem.so.1.65.1 /usr/lib/libboost_filesystem.so
sudo ln -s /usr/lib/x86_64-linux-gnu/libboost_system.so.1.65.1 /usr/lib/libboost_system.so
Done! R package velocyto.R was successfully installed!
This error may also be brought about if the symbolic link is to a dynamic library, .so, but for legacy reasons -static appears among the link flags. If so, try removing it.
The library I was trying to link to turned out to have a non-standard name (i.e. wasn't prefixed with 'lib'), so they recommended using a command like this to compile it -
gcc test.c -Iinclude lib/cspice.a -lm
I encountered the same error message.
I built the cmocka as a so and tried to link it to my executable.
But ld always complains below:
/usr/bin/ld: cannot find -lcmocka
It turns out that there are 3 files generated after cmocka is built:
libcmocka.so
libcmocka.so.0
libcmocka.so.0.7.0
1 and 2 are symbol links and only 3 is the real file.
I only copied the 1 to my library folder, where ld failed to find the 3.
After I copied all 3, ld works.
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 ...