-
-
Notifications
You must be signed in to change notification settings - Fork 6.4k
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
cannot configure curl 7.71.0 with static WolfSSL installed outside system directories #5605
Comments
This appears to be related to the changes in handling WolfSSL with NTLM and interplay with the WolfSSL Will have to tune my WolfSSL config a bit as I think the issue is there, not curl, but this was unexpected as I've been using something like this for months and multiple curl versions. Thanks! |
(we build with wolfSSL outside of system directories in our CI builds, so very frequently...) |
You can perhaps start by showing us the wolfSSL section from curl's configure output when it ran. |
Not the OP, but I see the same issue trying to build cURL 7.71.1 with wolfSSL in a Yocto environment. Quick testing shows that this breaks going from 7.70.0->7.71.0, which would relate it to this commit. It seems like the configure script is trying to take the pkg-config values even if I provide a path to the option. Configure invoked with:
WolfSSL section of config.log:
The actual part that fails is from the libssh2 tests right after that:
|
Ah, but that 's a slightly different use case though @a5ehren. When building cross-compiled, it shouldn't use the pkg-config file as it's usually not right for that. I'll submit a PR in a sec to address that. |
I've confirmed that the commit fixes the config step for my exact case (--with-wolfssl=), but the link for libcurl.so fails with "undefined reference to wolfSSL_DES_ecb_encrypt". This function is hidden behind an extra #ifdef when compared to wolfSSL_DES_set_odd_parity that is tested for in the configure script when checking to add NTLM support (at least in the two versions of wolfSSL I have access to - 4.3 and 4.4). This function (for whatever reason) only gets added to the OpenSSL compatibility layer if the user is building for stunnel, wpa_supplicant, or openVPN support - otherwise it is not present. Using the plain "--with-wolfssl" fails a Yocto QA check, because the addcflag, etc, doesn't get blanked back to defaults properly. I've got a pretty good idea of what to do to fix all this, so I'll be sending a PR in soon. |
Also choose a different wolfSSL function to test for NTLM support. Bug: curl#5605
Also choose a different wolfSSL function to test for NTLM support. Bug: curl#5605
Also choose a different wolfSSL function to test for NTLM support. Bug: curl#5605
I did this
On CentOS 7/x86_64...
libtoolize ; autoreconf -fiv
This works fine on 7.70.0 - just tested successfully to verify. On 7.71.0,
configure
errors out with:config.log
shows the following:I'm wondering where the bare /wolfssl is coming from and if the new
-L
handling in the autotools setup is causing this. The same pattern seems to work fine with OpenSSL/LibreSSL, mbedTLS, and bearssl, though, so I'm not sure what the difference is with WolfSSL, or if the-L
change is completely unrelated.I expected the following
A
src/curl
built with static wolfssl.curl/libcurl version
7.71.0
operating system
CentOS 7 (x86_64)
I tested under CentOS 6 (x86_64) as well with the same results.
The text was updated successfully, but these errors were encountered: