* upstream-curl:
curl 2023-09-13 (6fa1d817)
Upstream significantly refactored `lib/CMakeLists.txt`, so take the
upstream version of everything except the code added by commit
54cb23c657 (curl: Restore installation of OpenSSL DLLs, 2014-11-03,
v3.2.0-rc1~418^2~4). We will apply our customizations again in a
follow-up commit.
Upstream curl enabled this by default starting in curl 7.77. We merged
that version of curl in commit cd40922edb (Merge branch 'upstream-curl'
into update-curl, 2021-05-27, v3.21.0-rc1~120^2~2) but accidentally
switched HSTS off in the build system. Enable it now.
Restore changes from commit 2be5a7de4e (Build: Use imported target
`ZLIB::ZLIB` instead of variables, 2022-08-21, v3.25.0-rc1~97^2~10)
that were undone by the update to curl 8.0.1. The code was moved.
Revert commit c0a4536cec (curl: Disable schannel TLS 1.3 support on
Windows 11, 2022-11-09, v3.25.0~13^2). The curl bug it avoided was
fixed by upstream curl commit `4f42150d0` (sendf: change Curl_read_plain
to wrap Curl_recv_plain , 2022-11-14, curl-7_87_0~129), which we have
since recently updating to curl 7.87.0.
Issue: #24147
On a nightly build using LCC 1.23, OpenSSL 2.0.0 is found but does
not seem to have the `X509_STORE_up_ref` symbol used by curl 7.87.
Pending further investigation, disable use of the symbol based on
the compiler version.
Curl 7.85.0 introduced support for TLS 1.3 support with schannel.
We've observed connection failures in some cases, so disable the
support pending further investigation.
Fixes: #24147
LibreSSL older than 2.6.0 is not supported correctly
in upstream curl, and as a consequence, in libcmcurl.
Such LibreSSL versions can be used in old distros,
like OS Elbrus 4.x and 5.x, so until this fix, CMake
wasn't buildable there either.
Compile some third-party libraries with preprocessor definitions that
activate POSIX APIs even when compiler extensions are not enabled.
We already do this in libuv, inherited from the upstream buildsystem.
This extends commit f034b0f663 (CMake compilation: do not use compiler
extensions, 2020-03-14, v3.18.0-rc1~494^2).
Issue: #20454
Divert LCC compiler as a new one, instead of treating it as GNU.
Since old times, Elbrus C/C++/Fortran Compiler (LCC) by MCST has been
passing checks for GNU compilers, so it has been identified as GNU.
Now, with intent of seriously upstreaming its support, it has been
added as a separate LCC compiler, and its version displays not a
supported GCC version, but LCC version itself (e.g. LCC 1.25.19 instead
of GNU 7.3.0).
This commit adds its support for detection, and also converts basically
every check like 'is this compiler GNU?' to 'is this compiler GNU or
LCC?'. The only places where this check is untouched, is where it
regards other platforms where LCC is unavailable (primarily non-Linux),
and where it REALLY differs from GNU compiler.
Note: this transition may break software that are already ported to
Elbrus, but hardly relies that LCC will be detected as GNU; still such
software is not known.
Backport upstream curl commit `ee97f1769` (schannel: set ALPN length
correctly for HTTP/2, 2021-05-26) to get a fix to curl issue 7138,
a regression in 7.77.0.
Fixes: #22355
cURL detects the `send` and `recv` signatures using a large loop
of `try_compile` checks. The results are used for the following:
* Casting argument types in calls to `send` and `recv`, perhaps
to avoid conversion warnings. We compile with `-w` anyway.
* Providing debug variants for `CURLDEBUG`, which we do not use.
Replace the detection loops with hard-coded results that should work
well enough everywhere. This significantly reduces the number of
configure-time checks for building CMake on some platforms.
