How to Fix “error while loading shared libraries: cannot open shared object file: No such file or directory”

The error while loading shared libraries: cannot open shared object file: No such file or directory message typically occurs when Linux programs can’t locate the required shared library (.so) files at runtime. This issue commonly arises after installing or compiling software from source, or when libraries exist outside standard locations.

Method 1: Using the ldconfig Command

One of the quickest and most effective ways to resolve this error is by running the ldconfig command. This command refreshes the system’s cache of shared libraries, making newly installed libraries discoverable to the linker.

Open a terminal and execute the following command with superuser privileges:

sudo ldconfig -v

The -v option provides verbose output, showing you the libraries it detects and caches.

After running ldconfig, test your program again. In many cases, this step alone resolves the issue.

Method 2: Adding Library Path to LD_LIBRARY_PATH

If the library is installed in a non-standard location, you can manually specify its path using the LD_LIBRARY_PATH environment variable.

First, locate your shared library file (.so) using the find command. For example, to find libexample.so, run:

sudo find / -name libexample.so

Note the directory where the library is located.

Next, add this directory to your LD_LIBRARY_PATH environment variable. For example, if your library is in /usr/local/lib, execute:

export LD_LIBRARY_PATH=/usr/local/lib:$LD_LIBRARY_PATH

Test your program again to confirm the issue is resolved. To make this change permanent, add the above line to your shell profile (e.g., ~/.bashrc or ~/.bash_profile).

Method 3: Modifying the ld.so.conf File

A more permanent and system-wide solution is to add the library’s path to the /etc/ld.so.conf file. This approach ensures the dynamic linker always checks this directory for shared libraries.

Open the /etc/ld.so.conf file with a text editor (such as nano or vim):

sudo nano /etc/ld.so.conf

Add your library path (e.g., /usr/local/lib) on a new line at the bottom of the file. Do not remove existing entries. It should look similar to:

include ld.so.conf.d/*.conf
/usr/local/lib

Save the file and exit the editor. Then, update the linker cache by running:

sudo ldconfig

Verify your changes by checking the cache:

ldconfig -p | grep local

You should now see your added path and libraries listed. Test your application to ensure the error is resolved.

Method 4: Reinstalling or Installing Missing Libraries

If the library file is entirely missing, you’ll need to install the appropriate package.

Identify the package containing the missing library using your distribution’s package manager. On Debian or Ubuntu systems, you can search for the library using apt search:

apt search libexample

Once identified, install the package using:

sudo apt install package_name

After installation, update the linker cache again:

sudo ldconfig

Test your program to confirm the issue has been fixed.

Method 5: Linking Libraries at Compile Time

If you have control over the program’s compilation process, you can specify the library path directly during compilation.

When compiling your program, include the -Wl,-rpath option to specify the runtime library path. For example:

gcc your_program.c -o your_program -L/usr/local/lib -Wl,-rpath=/usr/local/lib -lyourlibrary

This explicitly tells the linker to embed the library’s path into your executable, eliminating the need to set environment variables or modify system files.

After compiling, run your program to ensure it works correctly.

These methods typically resolve the “cannot open shared object file” error effectively. Choose the solution that best fits your environment and requirements, and you’ll be back to running your applications smoothly in no time.