How to solve openssl error when loading shared libraries libssl.so.1.1

1. The purpose of this post

After install openssl, we run the openssl version to verity the installation, but sometimes we would get this error:

[root@node1 openssl-1.1.0f]# openssl version
openssl: error while loading shared libraries: libssl.so.1.1: cannot open shared object file: No such file or directory

2. Environments

The linux system is:

[root@node1 openssl-1.0.0f]# uname -a
Linux node1 3.10.0-862.14.4.el7.x86_64 #1 SMP Wed Sep 26 15:12:11 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

3. Debug

We try to find the file named libssl.so.1.1 as follows:

[root@localhost openssl-1.1.0f]# ll /usr/lib64/libssl*
-rwxr-xr-x. 1 root root 315096 8m   7 2017 /usr/lib64/libssl3.so
lrwxrwxrwx. 1 root root     16 7m   9 2009 /usr/lib64/libssl.so.10 -> libssl.so.1.0.2k
-rwxr-xr-x. 1 root root 470336 8m   4 2017 /usr/lib64/libssl.so.1.0.2k
[root@localhost openssl-1.1.0f]# ll /usr/local/lib64
Total 8984
drwxr-xr-x. 2 root root      39 11m  8 11:30 engines-1.1
-rw-r--r--. 1 root root 4967326 11m  8 11:30 libcrypto.a
lrwxrwxrwx. 1 root root      16 11m  8 11:30 libcrypto.so -> libcrypto.so.1.1
-rwxr-xr-x. 1 root root 2934272 11m  8 11:30 libcrypto.so.1.1
-rw-r--r--. 1 root root  766182 11m  8 11:30 libssl.a
lrwxrwxrwx. 1 root root      13 11m  8 11:30 libssl.so -> libssl.so.1.1
-rwxr-xr-x. 1 root root  521384 11m  8 11:30 libssl.so.1.1
drwxr-xr-x. 2 root root      61 11m  8 11:22 pkgconfig

We can find that the ‘libcrypto.so.1.1’ is located in the /usr/local/lib64, But openssl try to find the .so libraries in the LD_LIBRARY_PATH

[root@localhost ~]# echo $LD_LIBRARY_PATH
/usr/lib64:/usr/local/lib64

So the solution is try to tell openssl where the library is.

4. Solve it

There are two methods to solve the problem:

4.1 Method 1: Change the LD_LIBRARY_PATH

export LD_LIBRARY_PATH = /usr/local/lib64:$LD_LIBRARY_PATH

4.2 Method 2: Create a linke to the file

[root@localhost openssl-1.1.0f]# ln -s /usr/local/lib64/libssl.so.1.1 /usr/lib64/libssl.so.1.1
[root@localhost openssl-1.1.0f]# ln -s /usr/local/lib64/libcrypto.so.1.1 /usr/lib64/libcrypto.so.1.1

5. The LD_LIBRARY_PATH

As the linux documents shown:

You can temporarily substitute a different library for this particular execution. In Linux, the environment variable LD_LIBRARY_PATH is a colon-separated set of directories where libraries should be searched for first, before the standard set of directories; this is useful when debugging a new library or using a nonstandard library for special purposes. The environment variable LD_PRELOAD lists shared libraries with functions that override the standard set, just as /etc/ld.so.preload does. These are implemented by the loader /lib/ld-linux.so. I should note that, while LD_LIBRARY_PATH works on many Unix-like systems, it doesn’t work on all; for example, this functionality is available on HP-UX but as the environment variable SHLIB_PATH, and on AIX this functionality is through the variable LIBPATH (with the same syntax, a colon-separated list).

LD_LIBRARY_PATH is handy for development and testing, but shouldn’t be modified by an installation process for normal use by normal users; see ``Why LD_LIBRARY_PATH is Bad’’ at http://www.visi.com/~barr/ldpath.html for an explanation of why. But it’s still useful for development or testing, and for working around problems that can’t be worked around otherwise. If you don’t want to set the LD_LIBRARY_PATH environment variable, on Linux you can even invoke the program loader directly and pass it arguments. For example, the following will use the given PATH instead of the content of the environment variable LD_LIBRARY_PATH, and run the given executable: /lib/ld-linux.so.2 –library-path PATH EXECUTABLE Just executing ld-linux.so without arguments will give you more help on using this, but again, don’t use this for normal use - these are all intended for debugging.

You can find the full linux shared libary documents on Linux documents