J'ai une application qui utilise la classe QWebSocket mais pas SSL. Cela fonctionne bien lorsque j'exécute une version compilée avec Qt 5.3 mais qu'un exécutable Qt 5.7 se fige sur les avertissements suivants:
QSslSocket: cannot resolve CRYPTO_num_locks
QSslSocket: cannot resolve CRYPTO_set_id_callback
QSslSocket: cannot resolve CRYPTO_set_locking_callback
QSslSocket: cannot resolve ERR_free_strings
QSslSocket: cannot resolve EVP_CIPHER_CTX_cleanup
QSslSocket: cannot resolve EVP_CIPHER_CTX_init
QSslSocket: cannot resolve sk_new_null
QSslSocket: cannot resolve sk_Push
QSslSocket: cannot resolve sk_free
QSslSocket: cannot resolve sk_num
QSslSocket: cannot resolve sk_pop_free
QSslSocket: cannot resolve sk_value
QSslSocket: cannot resolve SSL_library_init
QSslSocket: cannot resolve SSL_load_error_strings
QSslSocket: cannot resolve SSL_get_ex_new_index
QSslSocket: cannot resolve SSLv2_client_method
QSslSocket: cannot resolve SSLv3_client_method
QSslSocket: cannot resolve SSLv23_client_method
QSslSocket: cannot resolve SSLv2_server_method
QSslSocket: cannot resolve SSLv3_server_method
QSslSocket: cannot resolve SSLv23_server_method
QSslSocket: cannot resolve X509_STORE_CTX_get_chain
QSslSocket: cannot resolve OPENSSL_add_all_algorithms_noconf
QSslSocket: cannot resolve OPENSSL_add_all_algorithms_conf
QSslSocket: cannot resolve SSLeay
QSslSocket: cannot resolve SSLeay_version
QSslSocket: cannot call unresolved function CRYPTO_num_locks
QSslSocket: cannot call unresolved function CRYPTO_set_id_callback
QSslSocket: cannot call unresolved function CRYPTO_set_locking_callback
QSslSocket: cannot call unresolved function SSL_library_init
QSslSocket: cannot call unresolved function SSLv23_client_method
QSslSocket: cannot call unresolved function sk_num
Je ne vois pas ces avertissements dans la version 5.3 (qui fonctionne correctement), ce qui suggère que je ne devrais pas les ignorer, comme demandé dans cette question . En outre, QT += network
est déjà dans mon src.pro .
J'ai été amené à croire que Debian a supprimé ces symboles du paquet openssl . Quelqu'un pourrait-il me dire ce qui se passe ici et comment je pourrais résoudre ce problème?
Je cours sur le tronçon Debian
$ uname -r
4.8.0-2-AMD64
J'ai openssl et libssl-dev installés
openssl is already the newest version (1.1.0c-2).
libssl-dev is already the newest version (1.1.0c-2).
J'ai essayé de l'exécuter avec Qt 5.3 et 5.7
$ qmake -v
QMake version 3.0
Using Qt version 5.7.1 in /usr/lib/x86_64-linux-gnu
TL; DR
Debian Stretch est livré avec OpenSSL 1.1; Qt utilise OpenSSL 1.0; donnez à Qt ce dont il a besoin:
apt install libssl1.0-dev
Réponse détaillée
À partir de cette réponse sur OpenSSL et Qt , j'ai trouvé un indice et j'ai affiché la version de la bibliothèque SSL utilisée pour la compilation et l'exécution, à l'aide de:
qDebug()<<"SSL version use for build: "<<QSslSocket::sslLibraryBuildVersionString();
qDebug()<<"SSL version use for run-time: "<<QSslSocket::sslLibraryVersionNumber();
qDebug()<<QCoreApplication::libraryPaths();
Et il affiche:
SSL version use for build: "OpenSSL 1.0.1e-fips 11 Feb 2013"
... lot of SSL warnings...
SSL version use for run-time: 0
("/opt/Qt/5.8/gcc_64/plugins", "/home/Project/..../build...Desktop_Qt_5_8_0_GCC_64bit-Release/src/release/build_linux_64")
Mais Debian Stretch est livré avec OpenSSL 1.1. Comme prévu, tous les threads sur le Web concernant ce problème sont vrais: il s'agit d'un problème de compatibilité de version de bibliothèque OpenSSL.
Je "apt install libssl1.0-dev" et le problème a été résolu. J'ai encore 2 avertissements SSL à propos de SSLv3, mais au moins c'est seulement un avertissement (j'ai lu quelque chose sur le Web à ce sujet, pas moyen de le retrouver).
SSL version use for build: "OpenSSL 1.0.1e-fips 11 Feb 2013"
QSslSocket: cannot resolve SSLv3_client_method
QSslSocket: cannot resolve SSLv3_server_method
SSL version use for run-time: 268443839
("/opt/Qt/5.8/gcc_64/plugins", "/home/Project/..../build...Desktop_Qt_5_8_0_GCC_64bit-Release/src/release/build_linux_64")
Résumé
Jusqu'à ce que Qt prenne en charge OpenSSL 1.1, vous pouvez soit:
J'ai eu le même problème sur un serveur Debian Stretch. Je l'ai corrigé avec l'aide du commentaire 7hibaults.
L'exécution de la commande ci-dessous a résolu le problème pour moi:
Sudo apt-get install libssl1.0-dev
La réponse de Fylhan ne fonctionne pas sous Debian Buster car libssl1.0-dev était un paquet de transition et n'est plus supporté.
Il y a un rapport de bogue sur le site Web de Qt et dans le commentaire de Giuseppe d'Angelo il existe les solutions de contournement suivantes:
Solution de contournement 1
Si votre distribution a un répertoire pour OpenSSL 1.0 avec le droit Les liens symboliques (par exemple, Arch a /usr/lib/openssl-1.0/libssl.so) utilisent LD_LIBRARY_PATH pour forcer la recherche de ce répertoire en premier.
Contournement 2
Créez votre propre répertoire avec des liens symboliques et utilisez LD_LIBRARY_PATH pour cette.
Contournement 3
Reconstruisez votre propre Qt.
Je pourrais résoudre le problème en utilisant la deuxième solution, les commandes détaillées ci-dessous dans mon cas:
mkdir openssl1.0 ; cd openssl1.0
cp /usr/lib/x86_64-linux-gnu/libssl.so.1.0.2 libssl.so.1.0.2
ln -s libssl.so.1.0.2 libssl.so
LD_LIBRARY_PATH="/path/to/dir/openssl1.0"
avant votre commande depuis la console)Vous pourriez également avoir besoin de faire de même avec libcrypto.so, mais cela me suffisait. Cette solution vous empêche de modifier les liens symboliques pour l'ensemble du système.
Vous devez installer le paquet suivant pour résoudre le problème.
Sudo apt install libssl1.0-dev