J'essaie de compiler openssl-1.1.0e sur Centos 7 (7.3.1611) , Mais après avoir tout compilé avec succès sans avertissement, j'obtiens une erreur en essayant une commande openssl
[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
Est-ce un bug ou mon erreur?
Ci-dessous quelques informations sur mon système/configuration
Configurez:
[mdm@dev openssl-1.1.0e]$ ./Configure linux-x86_64 --prefix=/usr/local --openssldir=/usr/local
Faire/Faire le 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
...
Faire installer:
...
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
...
Mais si je vérifie avec ldd deux bibliothèques ne sont pas trouvées malgré que Make install ait fait son travail ...
[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)
J'ai déjà installé par distro une version de openssl:
[mdm@dev]$ openssl version
OpenSSL 1.0.1e-fips 11 Feb 2013
[mdm@dev]$ which openssl
/usr/bin/openssl
miam 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
...
Appréciez toute aide ou suggestion!
Ok, parfois, quand vous voulez gravir la montagne, vous cherchez juste le sommet sans vérifier si quelque chose peut vous aider sur la base ... Dans mon cas, j'ai résolu d'exporter simplement LD_LIBRARY_PATH avant de le recompiler.
export LD_LIBRARY_PATH=/usr/local/lib:/usr/local/lib64
et après
Sudo ldconfig
cela devrait garder le chemin enregistré même après le redémarrage de la machine (et aussi pour les prochaines fois ;-))
Essaye ça:
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)
grâce à levitte, RenatoXSR
pour OpenSSL 1.1.0g
, CentOS 7.2.1511
, vous pouvez essayer ceci
Sudo bash -c "echo '/usr/local/lib64' >> /etc/ld.so.conf"
Sudo ldconfig
ce lien explique la cause du problème
L'utilisation de RPATH est incohérente. Sur certains systèmes, ld.so considère RPATH avant même d’examiner LD_LIBRARY_PATH, ce qui rend difficile le remplacement, par exemple lors du test d’une nouvelle version OpenSSL (!). Nous l'avons fait dans les versions antérieures à la version 1.1.0 en piratant LD_PRELOAD, mais certains désinfectants ne sont pas d'accord avec cela, ce qui rend également la vie difficile, par exemple lors du test d'une nouvelle version OpenSSL (!)
ce lien a donné un exemple de solution
Dans ce cas, vous devez configurer OpenSSL avec:
./Configure linux-x86_64 enable-ec_nistp_64_gcc_128 -Wl, -rpath =/usr/local/lib64\- préfixe =/usr/local --openssldir =/usr/local OpenSSL n'ajoute pas de RPATH par défaut (sauf sur certains BSD). Vous devez le spécifier manuellement dans votre commande configure. Une fois que vous le spécifiez manuellement, les choses "fonctionneront juste " Sans avoir besoin des astuces LD_LIBRARY_PATH.
j'ai suivi votre conseil mais toujours la même erreur si je ne spécifie pas LD_LIBRARY_PATH cela ne fonctionne pas de toute façon ...
[mdm@dev openssl-1.1.0e]$ export LD_LIBRARY_PATH=/usr/local/lib:/usr/local/lib64
[mdm@dev openssl-1.1.0e]$ ldd /usr/local/bin/openssl
linux-vdso.so.1 => (0x00007ffc87aef000)
/lib/$LIB/liblsp.so => /lib/lib64/liblsp.so (0x00007f57511fa000)
libssl.so.1.1 => /usr/local/lib/libssl.so.1.1 (0x00007f5750f8c000)
libcrypto.so.1.1 => /usr/local/lib/libcrypto.so.1.1 (0x00007f5750ae8000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f57508cb000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f57506ae000)
libc.so.6 => /lib64/libc.so.6 (0x00007f57502ed000)
/lib64/ld-linux-x86-64.so.2 (0x00007f5751401000)
[mdm@dev openssl-1.1.0e]$ openssl version
OpenSSL 1.1.0e 16 Feb 2017
Il semble que je doive utiliser LD_LIBRARY_PATH de toute façon Je me demande si c'est normal ou s'il s'agit simplement d'un problème de comportement sur ma machine pour certaines raisons que mes connaissances ne parviennent pas à comprendre ...
Configurez:
[mdm@dev openssl-1.1.0e]$ ./Configure linux-x86_64 --prefix=/usr/local --openssldir=/usr/local
Dans ce cas, vous devez configurer OpenSSL avec:
./Configure linux-x86_64 enable-ec_nistp_64_gcc_128 -Wl,-rpath=/usr/local/lib64 \
--prefix=/usr/local --openssldir=/usr/local
OpenSSL n'ajoute pas de RPATH par défaut (sauf sur certains BSD). Vous devez le spécifier manuellement dans votre commande configure. Une fois que vous le spécifiez manuellement, les choses "fonctionneront" pour vous sans avoir besoin des astuces LD_LIBRARY_PATH
.
Le enable-ec_nistp_64_gcc_128
est applicable à x86_64. Diffie-Hellman accélère de 2x à 4x. L'option a certaines restrictions, donc soyez prudent lorsque vous l'utilisez (mais vous êtes en sécurité sur x86_64).
Voir également Compilation et installation sur le wiki OpenSSL. Il y a une discussion sur les RPATH et une discussion sur enable-ec_nistp_64_gcc_128
.