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:
[[email protected] 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:
[[email protected] 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:
[[email protected] 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
[[email protected] 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
[[email protected] ~]# 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
[[email protected] openssl-1.1.0f]# ln -s /usr/local/lib64/libssl.so.1.1 /usr/lib64/libssl.so.1.1
[[email protected] 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