Linux lib cannot open shared object file

error while loading shared libraries: libpoppler.so.58: cannot open shared object file

I compiled and install poppler-0.39.0 as per the instruction. By default header files went int \usr\local\include and lib files went into \usr\local\lib . pdftohtml is installed in \usr\local\bin . Now when I tried to run pdftohtml it gives following error.

pdftohtml: error while loading shared libraries: libpoppler.so.58: cannot open shared object file: No such file or directory. 

2 Answers 2

I had a similar problem on Ubuntu 18.04. After installation I got this error:

error while loading shared libraries: libpoppler.so.90: cannot open shared object file: No such file or directory 

It turned out it was installed to /usr/local/lib :

Install the project. -- Install configuration: "RelWithDebInfo" -- Installing: /usr/local/lib/libpoppler.so.90.0.0 -- Installing: /usr/local/lib/libpoppler.so.90 -- Installing: /usr/local/lib/libpoppler.so -- Installing: /usr/local/lib/pkgconfig/poppler.pc -- Installing: /usr/local/lib/pkgconfig/poppler-splash.pc -- Installing: /usr/local/lib/pkgconfig/poppler-qt5.pc -- Installing: /usr/local/lib/pkgconfig/poppler-glib.pc -- Installing: /usr/local/lib/pkgconfig/poppler-cairo.pc -- Installing: /usr/local/lib/pkgconfig/poppler-cpp.pc 

but the system wasn’t looking there.

To check if /usr/local/lib is in the default directories to search you can take a look at /etc/ld.so.conf.d/libc.conf .

If not already there you can add: /usr/local/lib

In my case this was already the case:

# libc default configuration /usr/local/lib 

But the cache at /etc/ld.so.cache wasn’t updated.

To do so run (as root / sudo ):

Solved the problem for me. Hope this may be helpful for someone!

Источник

How to Fix “cannot open shared object file” Error in Ubuntu

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:

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.

We can then proceed and install it:

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.

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:

Also, confirm that the shared library is linked with your program.

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.

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.

Источник

How to Solve «cannot open shared object file» Error in Ubuntu-based Linux Distributions

Complete detailed solution for fixing “error while loading shared libraries” error in Ubuntu-based Linux distributions.

There is a list of common errors I often see in Ubuntu. There is problem with merge list, then there is BADSIG error, and a number of common Ubuntu update errors. One of such common errors which I often see while installing a program from its source code is error while loading shared libraries. The full error generally looks like this: error while loading shared libraries:
cannot open shared object file: No such file or directory For example, I was trying to use FreeRADIUS server and it showed me this error:

radiusd: error while loading shared libraries: libfreeradius-radius-2.1.10.so: cannot open shared object file: No such file or directory

The reason behind this error is that the libraries of the program have been installed in a place where the dynamic linker cannot find them. Let me show you how you can go about fixing this issue.

Fixing ‘cannot open shared object file: No such file or directory’ error

One quick way to fix this “error while loading shared libraries” automatically is to use ldconfig. All you need to do is to open the terminal (Ctrl+Alt+T) and type the following command:

This one-liner should solve the problem in most cases. However, if it doesn’t, I have discussed another method to handle this error. But before that, let me tell you what does the above command do.

What are shared object files? How does the above command fixes the issue?

You see, in C/C++, a .so (shared object) is a compiled library file. It is called shared object because this library file can be shared by several programs. These generated libraries are usually located in /lib or /usr/lib directories. Now if you wonder how did this tiny command fixed this problem, you should read the man page of ldconfig which says:

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). The cache is used by the run-time linker, ld.so or ld-linux.so. ldconfig checks the header and filenames of the libraries it encounters when determining which versions should have their links updated.

I hope this quick fix helps you in eliminating the nasty error while loading shared libraries message in Ubuntu and other Linux. If not, you can do some investigation and try to fix the issue the way it is mentioned in the next section.

An alternate method to fix ‘cannot open shared object file’ error

The above discussed method fixes the issue if the library in question is available in your system. But that may not always be the case. If you do not have the program installed on your system, you won’t have its library file. The ldconfig cannot do anything if there is no library file in the first place. So, the alternate method is to install the required program and it should create the library automatically. Let me show it to you by an example. Let’s say you see this error:

error while loading shared libraries: libgobject-2.0.so.0: cannot open shared object file: No such file or directory

The problem is with libgobject version 2.0. The version number is important because some programs depend on a specific version of the library and if they don’t find, they complain about it. Now, apt provides the search option that can be used for searching a package and knowing its version before installing it.

[email protected]:~$ apt search libgobject Sorting. Done Full Text Search. Done librust-gobject-sys-dev/focal 0.9.0-2 amd64 FFI bindings to libgobject-2.0 - Rust source code

Now, this librust-gobject-sys-dev package could be what you need if you know that you were trying to run a Rust program. But what if it was a Python program you were running that complained about it? You can widen your search by removing the lib from the package name while searching. The lib signifies library and libraries may be provided by a generic package that could be named gobject-xyz. It would be a good idea to search for the string in the names of the package (instead of descriptions) to get more concise results.

[email protected]:~$ apt search --names-only gobject Sorting. Done Full Text Search. Done gobject-introspection/focal-updates 1.64.1-1~ubuntu20.04.1 amd64 Generate interface introspection data for GObject libraries libavahi-gobject-dev/focal 0.7-4ubuntu7 amd64 Development headers for the Avahi GObject library libavahi-gobject0/focal 0.7-4ubuntu7 amd64 Avahi GObject library libcairo-gobject-perl/focal,now 1.005-2 amd64 [installed,automatic] integrate Cairo into the Glib type system in Perl libcairo-gobject2/focal,now 1.16.0-4ubuntu1 amd64 [installed,automatic] Cairo 2D vector graphics library (GObject library) libghc-gi-gobject-dev/focal 2.0.19-1build1 amd64 GObject bindings libghc-gi-gobject-doc/focal,focal 2.0.19-1build1 all GObject bindings; documentation 

In the above truncated output, you’ll have to see if the package is related to the original program you were trying to run. You must also check the version of the library provided. Once you have identified the correct package, install it like this:

sudo apt install package_name

Nothing works; what now?

If you are unfortunate enough, the above methods might not work for you. What can you do? First, keep in mind that the shared libraries may be used from other packages in some cases. If you were trying to run XYZ program and ABC program installs the correct version of the shared library, it may (or may not) work for you. You can give it a hit and trial. Second, if you are trying to run a program that is too old or too new, it may require a library version that is not available for your Linux distribution. What you may do is check if you can use some other version of the program—for example, using Eclipse version 3 instead of version 4. This may help your case. The other way would be to check the developer’s website or forums and see if you can manually install the correct version of the library from its source code. That requires a lot of effort (in 2020) but you don’t have a lot of options.

Did it work for you?

I hope I have made things a bit more clear for you. Did you manage to fix the issue of shared libraries in your system? If you have questions, or suggestions, feel free to drop a comment. Ciao 🙂

Источник