Bootstrap FreeKB - Apache (Web Server) - Resolve "cannot open shared object file"
Apache (Web Server) - Resolve "cannot open shared object file"

Updated:   |  Apache (Web Server) articles

Cannot open shared object file is commonly displayed when a program, such as Python or Apache, cannot loaded a shared object module library file, something like this.

libpcre.so.0: cannot open shared object file: No such file or directory

 

If you know the command that is producing "cannot open shared object file", you can try using the ldd command to list the shared libraries required by the program. Notice in this example that libpcre.so.0 is not found.

~]# ldd /opt/apache/bin/httpd 
        libpcre.so.0 => not found

 

You can try re-installing the package using apt-get install (on a Debian distribution) or dnf install or yum install (on a Red Hat distribution).

dnf install httpd

 

You can try using the locate command to see if the shared library can be found. If no output is returned, this means the locate command could not find the file.

locate libpcre.so.0

 

Almost always, the shared libraries are located in the /usr/lib64 directory. Notice in this example that there is no libpcre.so.0 file or symbolic link in the /usr/lib64 directory.

~]$ ll /usr/lib64 | grep -i pcre
lrwxrwxrwx   1 root root       16 Aug  3 04:08 libpcre.so -> libpcre.so.1.2.0
lrwxrwxrwx   1 root root       16 Oct 12  2017 libpcre.so.1 -> libpcre.so.1.2.0
-rwxr-xr-x   1 root root   402384 Feb  6  2017 libpcre.so.1.2.0

 

It's fairly common for older shared libraries to by symbolically linked to newer shared libraries. In this example, since there are higher versions of the libpcre shared library in the /usr/lib64 directory, the ln -s command can be used to create a symbolic link from the higher version of libpcre to the lower version of libpcre. Sometimes, this is all that is needed to resolve "cannot open shared object file".

ln -s /usr/lib64/libpcre.so.1 /usr/lib64/libpcre.so.0

 

If the path to the shared file is uncommon, such as /opt/foo/bar, the path to the shared file may need to be added to your $PATH or $LD_LIBRARY_PATH variable.

Because newer version of Linux, such as Red Hat 8 use OpenSSL version 11 whereas older versions of Linux such as Red Hat 7 use OpenSSL version 10. In this example, the system has OpenSSL version 1.1.1 (version 11) but not version 10.

[root@pldzweb011 lib64]# dnf list installed | grep -i openssl
apr-util-openssl.i686                                  1.6.1-9.el8                                 @System
apr-util-openssl.x86_64                                1.6.1-9.el8                                 @System
openssl.x86_64                                         1:1.1.1k-12.el8_9                           @System
openssl-devel.x86_64                                   1:1.1.1k-12.el8_9                           @System
openssl-libs.i686                                      1:1.1.1k-12.el8_9                           @System
openssl-libs.x86_64                                    1:1.1.1k-12.el8_9                           @System
openssl-pkcs11.i686                                    0.4.10-3.el8                                @System
openssl-pkcs11.x86_64                                  0.4.10-3.el8                                @System
python3-pyOpenSSL.noarch                               19.0.0-1.el8                                @System
xmlsec1-openssl.x86_64                                 1.2.25-4.el8                                @Syste

 

I resolved this by installing OpenSSL version 10.

dnf install compat-openssl10.x86_64

 

 

 




Did you find this article helpful?

If so, consider buying me a coffee over at Buy Me A Coffee



Comments


Add a Comment


Please enter a0e3b5 in the box below so that we can be sure you are a human.