There isn’t a perfect operating system user experience. We will always run into errors that are user-initiated, OS-initiated, or ones due to the installation or set up of an application package.
The good thing with errors associated with any Linux operating system distribution is that they are solutions in waiting. This article guide will walk us through solving the error “cannot open shared object file” which is somewhat prominent in Linux Ubuntu distributions.
Addressing Shared Libraries
Under the Linux operating system domain, shared libraries are responsible for various program-related re-usable functions.
For instance, we might be working on a user program that takes some input data; in this case, compressed files. The algorithmic approach to easily solve this program-creation challenge is to borrow from the zlib library instead of trying to implement the compression and decompression functions from scratch.
Therefore, by running the above-described program script, the shared zlib library will be loaded from launch.
The ldd command is useful when addressing shared libraries linked with a specific program. For instance, to show shared libraries associated with Python3, we would run the following command:
$ ldd /usr/bin/python3
The .so extension confirms that we are dealing with shared libraries.
When a shared library is missing or the Linux OS path to its location is non-standard, we are bound to run into the infamous error “cannot open shared object file”.
To solve this erroneous issue, we have to take the following approaches:
Solution 1: Missing Packages
At most times, the issue regarding this error could be because of a missing application package that is bundled with the missing shared library. For instance, if the error further suggests we are missing libexpat.so, we can use the Ubuntu system package manager to query its existence.
In this case, the term libexpat suggests library expat and we, therefore, need to search expat and not libexpat.
$ apt search expat
We can then proceed and install it:
$ sudo apt install expat
Solution 2: The LD_LIBRARY_PATH Variable
The LD_LIBRARY_PATH environment variable can be used to specify the directories that should be searched for missing shared libraries.
For instance, if we have program_x that is in need of the shared library libfoo.so located at /home/dnyce/libs/libfoo.so, we can include it to the LD_LIBRARY_PATH with the following command:
$ export LD_LIBRARY_PATH=/home/dnyce/libs
You can then confirm the shared library’s inclusion on the program’s path via the ldd command.
$ ldd ./program_x
The above command should list all shared libraries associated with program_x.
If you are sure of the shared library’s existence but can’t find it, you can use the find command to retrieve its absolute path.
$ find /home -type f -name shared_library_name.so
Solution 3: Permanently Configuring Library Path
The library search path for the missing shared library can be permanently set on /etc/ld.so.conf file as demonstrated below.
$ echo "/home/dnyce/libs" | sudo tee /etc/ld.so.conf
For the Ubuntu system to recognize this newly added path, run:
$ sudo ldconfig
Also, confirm that the shared library is linked with your program.
$ ldd ./program_x
Solution 4: The ldconfig Command
If the shared library search paths have been modified or newly shared libraries recently installed, you can execute the ldconfig command on your Linux terminal for the linker’s cache to be updated. Updating this cache informs your Ubuntu system of new or modified shared libraries.
$ ldconfig -p
This command updates the linker’s cache and prints the location of the associated shared libraries.
The Ubuntu error “cannot open shared object file” is now solvable.
