OpenSSL1.1.1没有libeay.dll和ssleay.dll

Posted 2020-11-27 lsgxeva

OpenSSL1.1.1没有libeay.dll和ssleay.dll

https://www.openssl.org/source/old/1.0.2/openssl-1.0.2j.tar.gz

http://slproweb.com/products/Win32OpenSSL.html

 

程序运行时报如下错误：

qt.network.ssl: QSslSocket: cannot resolve TLSv1_1_client_method
qt.network.ssl: QSslSocket: cannot resolve TLSv1_2_client_method
qt.network.ssl: QSslSocket: cannot resolve TLSv1_1_server_method
qt.network.ssl: QSslSocket: cannot resolve TLSv1_2_server_method
qt.network.ssl: QSslSocket: cannot resolve SSL_select_next_proto
qt.network.ssl: QSslSocket: cannot resolve SSL_CTX_set_next_proto_select_cb
qt.network.ssl: QSslSocket: cannot resolve SSL_get0_next_proto_negotiated

The complete explanation is that 1.0.x and 1.1.x do not have the same naming conventions for the generated libraries. OpenSSL 1.1.x has moved into what they call the “unified build system” and changed themselves the names of the libraries. This was done on purpose, mainly because these libraries are not binary compatible and should not be intermixed into projects or dlls deployed to replace 1.0.x with 1.1.x, and vice versa. So while previously in 1.0.x there were libeay32 and ssleay32, they are in 1.1.x named libssl and libcrypto(在1.0.x之前的版本中,文件为libeay32.dll和ssleay32.dll,在1.1.x之后的版本中，名字是libssl.dll和libcrypto.dll). That’s what happened upstream in OpenSSL. Read here also: https://marc.info/?l=openssl-dev&m=147223063610803&w=2 and there are tons of other discussions online you can tap to.

Beyond that, I also manipulate the suffixes in my builds. Namely, I append the MD[d] and MT[d] suffixes, so that it can be clearer when someone uses a library. This may not be very important when using DLLs, but with static builds chaos ensues if you mix them. So I made my own patches to produce these suffixes to the libraries.

I think that’s a complete answer now. I have also a suggestion for you:

You can download my build scripts if you still like to change the names of the library files in a different way and look at the patch, and modify it accordingly.
You can also skip the application of the patch and then you will get exactly the filenaming conventions of OpenSSL upstream in different builds.

I hope this helps.

 

http://www.npcglib.org/~stathis/blog/precompiled-openssl/

其实从1.0.2k就已经开始了

http://www.linuxfromscratch.org/blfs/view/svn/postlfs/openssl.html

对QT的影响：

Things that Broke in Qt

Here‘s what‘s broken in the dev branch of Qt when building openssl master as of 6 Feb 2015.

• DH - we were directly accessing p and q to set the DH params to primes embedded in Qt. We can probably replace this with SSL_CTX_set_dh_auto(ctx, 1). Another option suggested by Steve Henson is to save the DHparams we‘re using at the moment then use d2i_DHparams to load them in. This is compatible with openssl versions that don‘t have the dh_auto option.

• ctx->cert_store - we were directly accessing the cert_store field of SSL_CTX. We can probably replace this with X509_STORE *SSL_CTX_get_cert_store(SSL_CTX *ctx) [Fixed in dev]

• session->tlsext_tick_lifetime_hint - we were directly accessing the lifetime hint of the session. [A new API to access this field has been added]

• cipher->valid - we were directly accessing the valid field of SSL_CIPHER. No replacement found. [This turned out not to be needed and so will be removed].

https://wiki.openssl.org/index.php/1.1_API_Changes

 

所有openssl版本的变化列表：

https://abi-laboratory.pro/tracker/changelog/openssl/1.0.2j/log.html

https://abi-laboratory.pro/tracker/timeline/openssl/

https://www.openssl.org/news/openssl-1.0.2-notes.html
https://www.openssl.org/news/changelog.html

 

=============== End