New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Curl static compilation problem (X509_NAME) on Windows with BoringSSL 1.1.0 #5669
Comments
We build curl with current BoringSSL in the CI twice in every commit and PR, for Linux. Successfully... |
Yes, I think it's really a Windows specific issue |
I got something, but the way I solved it isn't very clean IMO : I had to undef X509_NAME and X509_EXTENSIONS after including wincrypt.h as USE_WIN32_CRYPTO seems to always be defined when compiling for windows In file ..\lib\vtls\openssl.c line 34:
Is there a better way to fix the issue ? |
And this issue isn't what #5606 already fixed then I presume? |
No response. This looks to be a duplicate of #5606. |
Sorry for late answer, It is not a duplicate of #5606 because it's not a problem of include order (this other problem is fixed as you said, and the latest commit I use include this fix in openssl.c) When compiling the openssl.c file, the wincrypt.h is included before openssl/base.h as it should so this is really not the issue : Note: including file: C:\Program Files (x86)\Windows Kits\10\include\10.0.19041.0\um\wincrypt.h The problem don't seems to be linked directly with Curl but . In fact it seems that the latest version of BoringSSL, and perhaps also OpenSSL, is completly incompatible with wincrypt.h because of the way X509_NAME and several things are declared or defined in both libraries . in wincrypt.h :
in openssl/base.h :
In both include order this will generate a conflict. The solution is to avoid using Win32 Crypto when OpsenSSL is used. This can be easily done by adding a simple condition where USE_WIN32_CRYPTO is defined when running CMake. In CMakeList.txt line 498 Change this
By this
I don't think this is a problem because I see no reason to use Win32 Crypto when OpenSSL/BoringSSL is available |
#5606 says OpenSSL undefines it, maybe BoringSSL doesn't and should?
I'm sure there is a reason for this but I don't recall offhand. /cc @jblazquez |
Yes I can confirm that it works "out of box" with OpenSSL. Another way to fix it at Curl level is to explicitly add undef statements in lib/vtls/openssl.c :
I think these two are enough |
As far as I can tell, the use of 148534d#diff-7dafef8d70eee3940c9184e4e4e93448 The code is only compiled when |
OpenSSL undefines the conflicting symbols but BoringSSL does not so we must do it ourselves. Reported-by: Samuel Tranchet Assisted-by: Javier Blazquez Fixes curl#5669 Closes #xxxx
OpenSSL undefines the conflicting symbols but BoringSSL does not so we must do it ourselves. Reported-by: Samuel Tranchet Assisted-by: Javier Blazquez Ref: https://github.com/openssl/openssl/blob/OpenSSL_1_1_1g/include/openssl/ossl_typ.h#L66-L73 Fixes curl#5669 Closes #xxxx
OpenSSL undefines the conflicting symbols but BoringSSL does not so we must do it ourselves. Reported-by: Samuel Tranchet Assisted-by: Javier Blazquez Ref: https://bugs.chromium.org/p/boringssl/issues/detail?id=371 Ref: https://github.com/openssl/openssl/blob/OpenSSL_1_1_1g/include/openssl/ossl_typ.h#L66-L73 Fixes curl#5669 Closes #xxxx
OpenSSL undefines the conflicting symbols but BoringSSL does not so we must do it ourselves. Reported-by: Samuel Tranchet Assisted-by: Javier Blazquez Ref: https://bugs.chromium.org/p/boringssl/issues/detail?id=371 Ref: https://github.com/openssl/openssl/blob/OpenSSL_1_1_1g/include/openssl/ossl_typ.h#L66-L73 Fixes curl#5669 Closes #xxxx
Thanks guys |
Same issue as here [1], but this time when building curl with BoringSSL for Windows with LDAP(S) or Schannel support enabled. Apply the same fix [2] for these source files as well. Though it can also be fixed by moving `#include "urldata.h"` _before_ `winldap.h` and `schnlsp.h` respectively. This seems like a cleaner fix, though I'm not sure why it works and if it has any downside. [1] curl#5669 [2] curl@fbe07c6
Same issue as here [1], but this time when building curl with BoringSSL for Windows with LDAP(S) or Schannel support enabled. Apply the same fix [2] for these source files as well. This can also be fixed by moving `#include "urldata.h"` _before_ `winldap.h` and `schnlsp.h` respectively. This seems like a cleaner fix, though I'm not sure why it works and if it has any downside. [1] curl#5669 [2] curl@fbe07c6
Same issue as here [1], but this time when building curl with BoringSSL for Windows with LDAP(S) or Schannel support enabled. Apply the same fix [2] for these source files as well. This can also be fixed by moving `#include "urldata.h"` _before_ `winldap.h` and `schnlsp.h` respectively. This seems like a cleaner fix, though I'm not sure why it works and if it has any downside. [1] curl#5669 [2] curl@fbe07c6
Same issue as here [1], but this time when building curl with BoringSSL for Windows with LDAP(S) or Schannel support enabled. Apply the same fix [2] for these source files as well. This can also be fixed by moving `#include "urldata.h"` _before_ including `winldap.h` and `schnlsp.h` respectively. This seems like a cleaner fix, though I'm not sure why it works and if it has any downside. [1] curl#5669 [2] curl@fbe07c6
Same issue as here [1], but this time when building curl with BoringSSL for Windows with LDAP(S) or Schannel support enabled. Apply the same fix [2] for these source files as well. This can also be fixed by moving `#include "urldata.h"` _before_ including `winldap.h` and `schnlsp.h` respectively. This seems like a cleaner fix, though I'm not sure why it works and if it has any downside. [1] #5669 [2] fbe07c6 Co-authored-by: Jay Satiro Closes #9110
I have a recent problem when I try to compile Curl static lib on windows with BoringSSL. The above commands where working fine 6 months ago, but with latest versions of Curl and BoringSSL I came into an issue in the nmake command.
I did this
I expected the following
I expected a successful build but I get the following in the console :
So I've investigated, and all the errors at the indicated lines seems to have in common the X509_NAME typedef usage, but the definition is correct in openssl/base.h:
typedef struct X509_name_st X509_NAME;
And in openssl/x509.h:
Furthermore the file ..\lib\vtls\openssl.c in Curl lib includes <openssl/x509v3.h> that includes <openssl/x509.h> that includes <openssl/base.h> ... So everything should be OK, but it's not.
The issue is also reported here.
curl/libcurl version
Latest commit on master branch
operating system
Windows 10 - Visual Studio 2019 16.6.3
The text was updated successfully, but these errors were encountered: