Error while loading shared libraries: /usr/local/lib64/libssl.so.1.1
Solution 1
Sometime when you want climb the mountain you looking just the top without checking if something can help you on the base...
In my case I solved just exporting LD_LIBRARY_PATH
before compile it again.
export LD_LIBRARY_PATH=/usr/local/lib:/usr/local/lib64
and after
sudo ldconfig
that should keep saved the path also after rebooting machine (and also for next times)
Solution 2
thanks to levitte, RenatoXSR
for OpenSSL 1.1.0g
, CentOS 7.2.1511
, you can try this
sudo bash -c "echo '/usr/local/lib64' >> /etc/ld.so.conf"
sudo ldconfig
this link explains the cause of problem
The use of RPATH is inconsistent. On some systems, ld.so considers RPATH before even looking at LD_LIBRARY_PATH, which makes it hard to override, for example when testing a new OpenSSL build (!). We did so in pre-1.1.0 versions by hacking LD_PRELOAD, but there are some sanitizers that do not agree with that, which makes life hard as well, for example when testing a new OpenSSL build (!)
this link gave an solution example
Solution 3
I know this is late but in my case I did not have the libssl.so.1.1
on my server.
There was a recommendation here to install openssl11-libs
but not openssl11
as installing it could create problems.
Confirm you dont have libssl.so.1.1
on your server probably by trying locate libssl.so.1.1
.
Simply do sudo yum install -y openssl11-libs
if you don't have the libssl.so.1.1
library on your server.
It worked for me.
Solution 4
Try this:
ldd libssl.so -> libcrypto.so.1.1 => not found
sudo ln -s /usr/local/lib64/libcrypto.so.1.1 /usr/lib64/libcrypto.so.1.1
libcrypto.so.1.1 => /lib64/libcrypto.so.1.1 (0x00007f17d46c7000)
Solution 5
Configure:
[mdm@dev openssl-1.1.0e]$ ./Configure linux-x86_64 --prefix=/usr/local --openssldir=/usr/local
In this case, you should configure OpenSSL with:
./Configure linux-x86_64 enable-ec_nistp_64_gcc_128 -Wl,-rpath=/usr/local/lib64 \
--prefix=/usr/local --openssldir=/usr/local
OpenSSL does not add RPATHs by default (except on some of the BSDs). You need to manually specify it in your configure command. Once you manually specify it, things will "just work" for you without the need for LD_LIBRARY_PATH
tricks.
The enable-ec_nistp_64_gcc_128
is applicable to x86_64. It makes Diffie-Hellman run 2x to 4x faster. The option has some restrictions, so be careful when using it (but you are safe on x86_64).
Also see Compilation and Installation on the OpenSSL wiki. There is a discussion of RPATHs, and a discussion of enable-ec_nistp_64_gcc_128
.
fromthestone
More problem solver than coder... More let it work than sysadmin...
Updated on February 04, 2022Comments
-
fromthestone about 2 years
I’m trying to compile openssl-1.1.0e on Centos 7 (7.3.1611) but after i successfully compiled everything without any warning, i get an error when i’m trying any openssl command
[mdm@dev openssl-1.1.0e]$ openssl version openssl: error while loading shared libraries: libssl.so.1.1: cannot open shared object file: No such file or directory
Is it a bug or my mistake?
Here below some info about my system/configuration
Configure:
[mdm@dev openssl-1.1.0e]$ ./Configure linux-x86_64 --prefix=/usr/local --openssldir=/usr/local
Make/Make test:
... All tests successful. Files=91, Tests=486, 44 wallclock secs ( 0.47 usr 0.08 sys + 27.72 cusr 13.41 csys = 41.68 CPU) Result: PASS ...
Make install:
... install libcrypto.a -> /usr/local/lib64/libcrypto.a install libssl.a -> /usr/local/lib64/libssl.a install libcrypto.so.1.1 -> /usr/local/lib64/libcrypto.so.1.1 link /usr/local/lib64/libcrypto.so -> /usr/local/lib64/libcrypto.so.1.1 install libssl.so.1.1 -> /usr/local/lib64/libssl.so.1.1 link /usr/local/lib64/libssl.so -> /usr/local/lib64/libssl.so.1.1 ...
But if i check with ldd two libraries are not found despite Make install did its job...
[mdm@dev openssl-1.1.0e]$ ldd /usr/local/bin/openssl linux-vdso.so.1 => (0x00007fffcfe75000) /lib/$LIB/liblsp.so => /lib/lib64/liblsp.so (0x00007fa5cd77a000) libssl.so.1.1 => not found libcrypto.so.1.1 => not found libdl.so.2 => /lib64/libdl.so.2 (0x00007fa5cd55d000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fa5cd341000) libc.so.6 => /lib64/libc.so.6 (0x00007fa5ccf7f000) /lib64/ld-linux-x86-64.so.2 (0x00007fa5cd981000)
I have already installed by distro a version of openssl:
[mdm@dev]$ openssl version OpenSSL 1.0.1e-fips 11 Feb 2013 [mdm@dev]$ which openssl /usr/bin/openssl
yum info openssl:
... Installed Packages Name : openssl Arch : x86_64 Epoch : 1 Version : 1.0.1e Release : 60.el7_3.1 Size : 1.5 M Repo : installed From repo : updates ...
Appreciate any help or suggestion!
-
jww about 7 yearsWhat does
/sbin/ldconfig -p
have to offer? Does it show the libraries after an install? Does/sbin/ldconfig -n /usr/local/lib64
help? -
fromthestone about 7 yearsyeah, now it's using lib64:
libssl.so.1.1 => /usr/local/lib64/libssl.so.1.1 (0x00007f48a2c45000) libcrypto.so.1.1 => /usr/local/lib64/libcrypto.so.1.1 (0x00007f48a27a1000)
@jww
-
-
fromthestone about 7 yearshere a similar issue on openssl github issue #1740
-
jww about 7 years
libssl.so.1.1 => /usr/local/lib/libssl.so.1.1
andlibcrypto.so.1.1 => /usr/local/lib/libcrypto.so.1.1
seems to indicate your are installing into/usr/local/lib
, and not/usr/local/lib64
. I thought Red Hat and friends like Fedora and CentOS usedlib64
. I suppose you should use-Wl,-rpath=/usr/local/lib
instead. Maybe you should print theldd
cache with/sbin/ldconfig -p
, too. It might have something unexpected. -
fromthestone about 7 yearsI have used lib64 because RH & friends working with lib64 everywhere
-
fromthestone about 7 yearsI think that pointing a symlink to systemwide /lib64 could be not a good idea. In my humble opinion is better to separate what you compiling locally, with what is managed by your system