How to Fix ‘Cannot Open Shared Object File: No Such File or Directory’ in Linux

Launching a compiled binary, running a command-line utility, or executing a custom application in Linux only to receive the fatal error “error while loading shared libraries: libXYZ.so: cannot open shared object file: No such file or directory” indicates that the dynamic linker cannot locate required shared library dependencies. In Linux, dynamically linked executables do not bundle every function within the binary; instead, the kernel runtime loader (ld.so or ld-linux.so) resolves dynamic library calls from shared objects (.so files) at runtime. When an essential library package is missing, installed in an unindexed custom path, or compiled for a different processor architecture (e.g., 32-bit vs 64-bit), the loader aborts process execution. This guide explains how to identify missing dependencies, install prerequisite library packages, and configure the dynamic linker cache.

What Causes the ‘Cannot Open Shared Object File’ Error?

The Linux dynamic linking mechanism checks specific directories defined in the system cache before failing:

• Uninstalled Shared Library Packages: The binary depends on an external runtime library (such as OpenSSL, libssl, or libncurses) that has not been installed on the system.
• Unindexed Library Directories: Software installed into custom prefixes (such as /usr/local/lib or /opt/myapp/lib) where the loader has not been informed of the path.
• Outdated Dynamic Linker Cache: A newly installed library file exists on disk, but the binary cache at /etc/ld.so.cache has not been refreshed using ldconfig.
• Architecture Multi-Arch Mismatch: Attempting to run a 32-bit (i386/i686) executable on a 64-bit (x86_64) system without 32-bit compatibility libraries installed.
• Symlink Version Number Discrepancies: The system has libexample.so.2 installed, but the legacy binary strictly expects a symbolic link named libexample.so.1.

Method 1: Identify Missing Dependencies Using ldd

The ldd utility prints all shared object dependencies required by an executable along with their resolution status.

1. Open your Linux terminal.
2. Run ldd against your target executable:

   ldd /path/to/your/program

3. Examine the console output. Look for any library entry that states “not found”:

   libssl.so.1.1 => not found
   libcrypto.so.1.1 => not found
   libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f9...)

4. Note the exact missing filename (e.g., libssl.so.1.1) to target for installation.

Method 2: Search and Install the Missing Library via Package Manager

Determine which native repository package provides the missing shared library file.

1. On Debian / Ubuntu systems, use apt-file to locate the package containing the library:

   sudo apt update
   sudo apt install -y apt-file
   sudo apt-file update
   apt-file search libssl.so.1.1

2. Install the identified package using apt:

   sudo apt install libssl1.1

3. On RHEL / CentOS / Fedora systems, search using dnf provides:

   sudo dnf provides "*/libssl.so.1.1"
   sudo dnf install openssl1.1

4. On Arch Linux, query using pacman -F:

   sudo pacman -Fy
   pacman -F libssl.so.1.1

Method 3: Update the Dynamic Linker Cache with ldconfig

If the shared object is already present on disk in a standard directory, refresh the kernel linker index.

1. Verify whether the missing library exists anywhere on your system:

   sudo find / -name "libXYZ.so*" 2>/dev/null

2. If the library exists in a standard library directory (such as /usr/lib or /usr/local/lib), rebuild the dynamic linker cache:

   sudo ldconfig

3. Query the cache to verify the library is now registered:

   ldconfig -p | grep libXYZ

4. Re-run your program to verify that the loader resolves the shared object.

Method 4: Add Custom Directories to ld.so.conf

For custom software suites stored in non-standard directories, permanently register their library folder with the system linker.

1. Create a custom configuration file in /etc/ld.so.conf.d/:

   sudo nano /etc/ld.so.conf.d/custom-software.conf

2. Add the full directory path where your application libraries reside:

   /usr/local/lib
   /opt/myapp/lib

3. Save the file (Ctrl + O, then Enter) and exit nano (Ctrl + X).
4. Rebuild the dynamic cache:

   sudo ldconfig

Method 5: Set the LD_LIBRARY_PATH Environment Variable

For portable applications or non-root environments where system files cannot be modified, specify the search path at runtime.

1. Test executing the application by prefixing LD_LIBRARY_PATH:

   LD_LIBRARY_PATH=/opt/myapp/lib:$LD_LIBRARY_PATH /path/to/your/program

2. To make this variable persistent for your user session, append it to your shell configuration profile:

   echo 'export LD_LIBRARY_PATH=/opt/myapp/lib:$LD_LIBRARY_PATH' >> ~/.bashrc
   source ~/.bashrc