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: