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 command 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.