Linux error while loading shared libraries: cannot open shared object file: No such file or directory

Question

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?

This might happen if you have recently installed a shared library and didn't run ldconfig(8) afterwards. Do 'ldconfig', there's no harm in it. — AbiusX, Jun 05 '11 at 21:02
+1 to @AbiusX comment - running sudo ldconfig (assuming that libraries are in fact where they should be [/usr/bin/lib/, /usr/bin/include/, /usr/local/lib/ and /usr/local/include/ AFAIK], please correct me if I'm wrong) can resolve that problem. Cheers! — AeroCross, Nov 16 '11 at 18:11
Note that this error can also arise if the permissions on your lib file got changed somehow. Changing the permissions back to 644 solved it for me. — Geoffrey H, Jan 28 '19 at 12:25
@AbiusX I ran sudo ldconfig after compiling my program and it worked. Thanks! (The libraries were in /usr/local/lib.) — kleinbottle4, Mar 07 '21 at 10:54
we need an update for this. its posted in 2009 for god sake its still happening — greendino, Jul 02 '21 at 11:37
came here with the same problem. hmmm as far as I know I don't have .so.1 files. But I have the lib with .so — user99999991, Jul 16 '21 at 22:28
what "update" do you need? there's three good answers to it, some of which may be applicable depending on your specific issue. — zaratustra, Feb 02 '23 at 13:52

score 555 · Answer 1 · edited Mar 08 '22 at 15:36

555

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

edited Mar 08 '22 at 15:36

MC Emperor

22,334
15
80
130

answered Jan 16 '14 at 22:07

XOR

5,986
2
16
10

4

The above mentioned answer was very clear, Thanks you first of all. I tried doing this in my Eclipse CDT Project Path (Lubuntu). /Debug$ echo $LD_LIBRARY_PATH /home/akhil/HDE/x86.linux/lib:/home/akhil/HDE/x86.linux/lib.. "/home/akhil/HDE/x86.linux/lib" this is where my libraries are actually available even, but still I get the same error. Any suggestions! – nahasapeemapetilon Jul 12 '16 at 11:44
24

Try a "ldconfig" command after exporting your library. You might need to execute this command as "sudo". – XOR Sep 26 '16 at 16:53
8

I believe `LD_LIBRARY_PATH` should point to the directory containing `path.so.something`, not to `path.so.something` itself. – gerrit Jun 23 '17 at 15:47
1

This is the right solution for the systems where `sudo ldconfig` cannot be executed, e.g. supercomputers. – Herpes Free Engineer Apr 16 '18 at 19:22
2

The `export LD_LIBRARY_PATH` command is essential so that other programs can read the environment variable. Without it only the shell can see the variable. – Zenul_Abidin Feb 13 '20 at 06:05
if you put the export command in a .sh file and you find that it LD_LIBRARY_PATH is not set after the .sh completes, run it as follows: . ./abc.sh (There's a dot at the beginning of that line) – kalyanswaroop Feb 02 '21 at 21:40
1

Read: http://xahlee.info/UnixResource_dir/_/ldpath.html <- or google Why LD_LIBRARY_PATH is (evil|bad). It does have it's purpose. – fbicknel May 25 '21 at 18:42
1

When `find / -name the_name_of_the_file.so` doesn't yield any results, you can try `sudo find / -iname *the_name_of_the_file*.so*` as [described in this answer.](https://stackoverflow.com/a/28460293/4575793) – Cadoiz Oct 18 '21 at 10:19
@fbicknel that link does say that sometimes you are _forced_ to use `LD_LIBRARY_PATH` even if it’s not something it was designed for. – bfontaine Jan 04 '23 at 09:08

score 241 · Answer 2 · edited May 23 '17 at 11:47

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

By default, /lib and /usr/lib but not /usr/local/lib? That has thrown me off several times over my career and wasted hours. — DarenW, Mar 15 '15 at 22:15
Adding `.conf` files of my own with the non-standard lib paths I need to `/etc/ld.so.conf.d` (pointed to by `/etc/ld.so.conf`) did the trick. — CivFan, Jan 27 '16 at 20:42
+1 for needing to run ldconfig. I wasn't using a package manager. I had to compile from source, so this was necessary. — Jeff, Dec 09 '16 at 17:06
Just like @CivFan, I added my own .conf in `/etc/ld.so.conf.d`. After which I (obviously) had to run ldconfig and it worked. I can feel you @DarenW. Its a pain in the butt — Hemil, Sep 26 '19 at 10:37
For anybody concerned: [`find -iname ...` is the same as `-name`, but case insensitive. But be wary: it is not part of the standard, so could be absent in the implementation you use.](https://unix.stackexchange.com/a/230954/318461) — Cadoiz, Oct 18 '21 at 10:14

score 150 · Answer 3 · edited Oct 21 '21 at 15:18

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.

... oh god, the .1 is part of the filename. Any idea what does it mean? — zaratustra, Jan 26 '09 at 18:21

score 49 · Answer 4 · edited Dec 18 '20 at 23:20

49

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/.

edited Dec 18 '20 at 23:20

Julia

1,950
1
9
22

answered Mar 23 '16 at 16:29

TaoCHEN92

533
4
6

7

This is the option I was looking for. Perhaps better would be `-Wl,-rpath DIR`. – jrw32982 Mar 31 '17 at 20:14
This is the personal turning point in my programming-enthusiast life. It's awesome. Thank you! – Max Herrmann Feb 16 '23 at 16:31

score 32 · Answer 5 · edited Nov 14 '19 at 18:53

32

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!

edited Nov 14 '19 at 18:53

Luce

184
2
9

answered Jul 07 '14 at 13:21

Ankit Marothi

955
10
14

3

After that, the following line should be added to the .bashrc export LD_LIBRARY_PATH – user216652 Sep 02 '20 at 23:28

score 14 · Answer 6 · edited Oct 18 '21 at 14:35

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.

score 8 · Answer 7 · edited Oct 29 '17 at 18:54

8

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

edited Oct 29 '17 at 18:54

Community

1
1

answered Jun 21 '16 at 17:36

singingsingh

1,364
14
15

ALM865 · Answer 8 · 2015-10-06T05:00:58.473

6

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.

edited Oct 06 '15 at 05:00

answered Sep 15 '15 at 23:58

ALM865

1,078
13
21

Could this be done for different version? In my case, I have libnsl.so.2, but my command is looking for libnsl.so.1. – Nathan Russell Feb 28 '23 at 16:42
To add to this answer, you can see which directories the linker is looking for the libraries in with `ld --verbose | grep SEARCH_DIR` and check for such near-matches. In my case, I had a problem where I had a `libgcr-4.so.4.0.0` in `/usr/lib` but no `libgcr-4.so.4`, so all I had to do was create a symlink like this answer says and it fixed it. – Eric Pedley May 18 '23 at 00:13

score 6 · Answer 9 · answered Jan 03 '18 at 07:44

6

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.

answered Jan 03 '18 at 07:44

Anand Paul

224
2
10

`gedit` ? You manipulate system configuration file with GUI? wowwwww – PersianGulf May 26 '22 at 15:07

score 5 · Answer 10 · edited Oct 21 '21 at 14:29

5

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

edited Oct 21 '21 at 14:29

Cadoiz

1,446
21
31

answered Jun 21 '21 at 15:51

robertspierre

3,218
2
31
46

`sudo ldconfig ` worked for me. Thanks. – Maf Jul 18 '23 at 06:21

score 4 · Answer 11 · edited Nov 07 '18 at 20:17

4

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
```

edited Nov 07 '18 at 20:17

zx485

28,498
28
50
59

answered Oct 31 '17 at 16:01

Michael Fayad

1,216
1
17
38

score 3 · Answer 12 · edited Oct 19 '21 at 03:57

3

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.

edited Oct 19 '21 at 03:57

Bazer Con

105
4

answered Feb 27 '16 at 12:33

Rubens Gomes

482
5
10

score 2 · Answer 13 · edited Sep 23 '21 at 23:07

2

Try to install lib32z1:

sudo apt-get install lib32z1

edited Sep 23 '21 at 23:07

Jackdaw

7,626
5
15
33

answered Jan 07 '14 at 14:34

zajac.m2

1,218
14
13

score 2 · Answer 14 · edited Oct 20 '21 at 23:22

2

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

edited Oct 20 '21 at 23:22

Bazer Con

105
4

answered Jun 02 '20 at 17:06

prabhugs

742
7
20

score 1 · Answer 15 · answered Mar 16 '15 at 13:56

1

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.

answered Mar 16 '15 at 13:56

jonny

3,022
1
17
30

score 1 · Answer 16 · edited Jun 19 '18 at 17:45

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.

score 1 · Answer 17 · edited Jun 19 '18 at 18:02

1

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)

edited Jun 19 '18 at 18:02

Vega

27,856
27
95
103

answered Jun 19 '18 at 17:47

Salmi Ahmed

11
3

Mohamad Osama · Answer 18 · 2021-10-18T11:22:31.107

0

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 *

edited Oct 18 '21 at 11:22

answered Apr 07 '18 at 09:36

Mohamad Osama

858
9
10

score 0 · Answer 19 · edited Oct 19 '21 at 11:41

0

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

edited Oct 19 '21 at 11:41

Denis

2,622
3
22
24

answered Jul 10 '19 at 00:55

MohamedAmin Samet

134
1
1
10

Linux error while loading shared libraries: cannot open shared object file: No such file or directory

19 Answers19

ldconfig

Dev package or wrong version

Library location

Linked

Related