| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
* upstream-curl:
curl 2023-05-30 (7ab9d437)
|
|
|
|
| |
Also avoid using the result without checking for NULL.
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
* upstream-curl:
curl 2023-03-20 (b16d1fa8)
|
|
|
|
|
| |
* upstream-curl:
curl 2023-02-20 (046209e5)
|
|
|
|
|
|
|
| |
Backport upstream curl commit `16bb32e104d` (sectransp: fix for
incomplete read/writes, 2023-01-05) to fix TLS support on macOS.
Fixes: #24398
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
* upstream-curl:
curl 2022-12-21 (c12fb3dd)
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
* upstream-curl:
curl 2022-10-26 (cd95ee9f)
|
| |
|
|
|
|
| |
Fixes: #23772
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
| |
* upstream-curl:
curl 2022-05-11 (462196e6)
|
|
|
|
|
| |
* upstream-curl:
curl 2022-04-27 (1669b17d)
|
| |
|
| |
|
|
|
|
|
| |
* upstream-curl:
curl 2022-01-05 (801bd513)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
* upstream-curl:
curl 2021-09-22 (c7aef0a9)
|
| |
|
|
|
|
|
| |
* upstream-curl:
curl 2021-09-14 (8e82f2a0)
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
| |
* upstream-curl:
curl 2021-05-26 (6b951a69)
|
| |
|
| |
|
|
|
|
|
| |
* upstream-curl:
curl 2021-02-03 (2f33be81)
|
| |
|
| |
|
|
|
|
|
| |
* upstream-curl:
curl 2020-12-09 (e0528597)
|
| |
|
|
|
|
|
| |
* upstream-curl:
curl 2020-08-19 (9d954e49)
|
|
|
|
|
| |
* upstream-curl:
curl 2020-06-30 (5a1fc8d3)
|
| |
|
|
|
|
|
| |
* upstream-curl:
curl 2020-06-23 (e9db32a0)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
* upstream-curl:
curl 2020-03-04 (b8d13668)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When building with the built-in Curl, CMAKE_USE_OPENSSL is only set
to ON by default if an OpenSSL installation is detected. However, this
can cause the user to mistakenly build without OpenSSL support if
OpenSSL is not installed, because CMAKE_USE_OPENSSL is set to OFF in
that case. Always set CMAKE_USE_OPENSSL to ON by default on systems
where it could be available, skipping the initial detection, resulting
in an error when we try to use OpenSSL later on. Detect this error
and advise the user to either install OpenSSL or set CMAKE_USE_OPENSSL
to OFF.
Co-Authored-by: Brad King <brad.king@kitware.com>
|
| |
|
| |
|
|
|
|
|
| |
* upstream-curl:
curl 2019-05-22 (885ce314)
|
| |
|