- fail if all retries failed.
- run `dpkg --configure -a` after an aborted slow attempt.
```
Selecting previously unselected package libsys-hostname-long-perl.
Error: slow server, retry
E: dpkg was interrupted, you must manually run 'sudo dpkg --configure -a' to correct the problem.
[...]
```
Bug: https://github.com/curl/curl/pull/21107#issuecomment-4163506100
Follow-up to 5172ba5475#21107Closes#21181
It's been going on for almost a year, chances seem slim to have this
fixed upstream.
The observed issue is that on GitHub-supplied CI runner images,
sometimes, `apt-get install` using the stock distro server
`http://azure.archive.ubuntu.com/ubuntu` sees extreme slowness while
downloading data, then reaching the job timeout and aborting, making CI
red and necessitating a manual restart of the failed job(s).
In majority of cases the install step takes no longer than 8-40 seconds
(download + install), while in the failing case it takes 10-20+ minutes
just to download.
Earlier I slimmed down installs to avoid unnecessary packages, which
mitigated, but did not completely fix the issue.
Example:
https://github.com/curl/curl/actions/runs/23599596928/job/68725576899?pr=21105
Follow-up to 0455d8772a#18509Closes#21107
To avoid rate limits when accessing GH APIs during the build.
Aiming to avoid (while trying to retrieve a file timestamp):
```
++ [[ 2026-02-11-1a84aee6387d2f9c9531c655edeea4a80aa0fcfa =~ (.+)-([a-f0-9]{40,}) ]]
++ ver=2026-02-11
++ commit=1a84aee6387d2f9c9531c655edeea4a80aa0fcfa
++ set +x
curl: (22) The requested URL returned error: 403
curl: (22) The requested URL returned error: 403
curl: (22) The requested URL returned error: 403
curl: (22) The requested URL returned error: 403
[...]
```
Ref: https://github.com/curl/curl/actions/runs/23598912140/job/68723120977?pr=21104
Follow-up to:
a26898fe4817f2fb3ead6dd6e47e98b461404b5aCloses#21105
Verify if lines are not longer than 192 characters. Also verify if lines
have less than 79 repeat spaces (and fix one fallout).
To improve readability by avoiding long lines and to prevent adding
overly long lines with text that may go unnoticed in an editor or diff
viewer.
In addition to pre-existing line length limits: 79 for C, 132 for CMake
sources.
Also:
- spacecheck: fix/harden allowlist regexes.
- spacecheck: tidy-up quotes and simplify escaping.
- spacecheck: allow folding strings with repeat spaces.
- GHA: fix a suppressed shellcheck warning.
- GHA/macos: simplify by dropping brew bundle.
- test1119.pl: precompile a regex.
- FAQ.md: delete very long link to a Windows 7/2008 support article
that's lost it relevance.
Closes#21087
c-ares builds have been sped up within curl-for-win using, pre-fills. It
allows building it with acceptable performance, making it practical to
use it, alongside HTTPS-RR, in curl CI and possibly in curl-for-win. It
has been enabled in its dev branch for a while.
Ref: 61a7354120Closes#21032
After limiting `find_package()`/`find_dependency()` calls to curl local
Find modules via the `MODULES` keyword, it became possible to detect
dependencies via CMake Configs from within those local Find modules, by
calling `find_package()` again with the `CONFIG` keyword. This patch
implements this. Then maps detection results to the result variables and
curl-specific imported targets the rest of the build expects.
Also honor recently introduced `*_USE_STATIC_LIBS` (experimental) flags
to map to the static target when requested.
This adds CMake Configs as an alternative to the existing `pkg-config`
and `find_path()`/`find_library()` auto-detection methods.
Enabled by default for MSVC, outside vcpkg and when not cross-building.
To enable for other cases, or override the default, you can use
`-DCURL_USE_CMAKECONFIG=ON` or `OFF`.
When enabled, Config detection happens after `pkg-config` and before
`find_path()`/`find_library()`. Using CMake's built-in options, you may
also manually point to the absolute directory holding Config files:
`Libssh2_DIR`, `MbedTLS_DIR`, `NGHTTP2_DIR`, `NGHTTP3_DIR`,
`NGTCP2_DIR` v1.19.0+ (with non-fork OpenSSL only), `Zstd_DIR` v1.4.5+
E.g. `-DMbedTLS_DIR=/path/to/mbedtls/lib/cmake/MbedTLS`
These dependencies typically need to be built with CMake to support
this.
Tagged as experimental.
Refs:
#20013#19156#19117https://github.com/curl/curl/pull/20784#issuecomment-3984318492
Depends-on: fad1ebaecc#20840
Follow-up to 91e06fde1b#20784
Follow-up to 26c39d8df1#20015Closes#20814
- librtmp has no test cases, makes no proper releases and has not had a
single commit within the last year
- librtmp parses the URL itself and requires non-compliant URLs for this
- we have no RTMP tests
- RTMP was used by 2.2% of curl users (self-identified in the 2025
survey)
Closes#20673
Require CMake 3.18 (2020-07-15) or newer, up from 3.7 (2016-11-11)
prior to this patch.
This requirement also applies to the distributed `curl-config.cmake`.
To allow dropping compatibility code maintained for old versions, and to
use features which were unpractical in separate code paths. Also to make
testing, documentation and development easier, CI builds faster due to
CMake performance improvements over time. (e.g. integration tests on
macOS run 8x faster (10 minutes is now under 1.5m) in CI, 2.5x faster on
Windows.)
CMake offers pre-built binaries for major platforms. They work without
an install step, just by unpacking and pointing the cmake command to
them. Making upgrades easy in many cases:
https://cmake.org/download/https://cmake.org/files/https://github.com/Kitware/CMake/releases
CMake 3.18 brings these feature as generally available when building or
consuming curl/libcurl:
LTO support, improved performance, `pkg-config` and interface target
support, `OBJECT` target (for faster libcurl builds), modern invocation
with `-S`/`-B` options, better support for custom linker options,
FetchContent, `GnuTLS::GnuTLS` target, `--verbose` and `--install`
options, `CMAKE_GENERATOR` env, last but not least unity mode and Ninja
generator.
For maximum build speed, use:
`-DCMAKE_UNITY_BUILD=ON -DCURL_DROP_UNUSED=ON`
As for deprecations, C++11 is required to build CMake itself, which may
be a limit on some platforms. autotools continues to cover them.
Follow-up to 9bcdfb3809#20408
Follow-up to a7c974e038#19902
Follow-up to dfbe035c8b#10161
Discussion: https://github.com/curl/curl/discussions/18704Closes#20407
By generalizing Homebrew prefix in shared code paths, where missing.
No strong reason, sometimes it's useful for tests.
Follow-up to e5316069f1#18818Closes#21019
ngtcp2 1.14.0 added module dependencies to `ngtcp2_crypto_*.pc` files.
This broke certain build cases in curl, because configure was is
querying pkg-config modules by setting `PKG_CONFIG_LIBDIR` to the
directory specified via `--with-*=` options, including `--with-ngtcp2=`.
Setting `PKG_CONFIG_LIBDIR` tells pkg-config (and pkgconf) to ignore
system locations. This caused that `ngtcp2_crypto_gnutls.pc` could no
longer find its indirect dependencies, if those were present at system
locations (where they typically are). Another fallout was BoringSSL,
because it does not provide `openssl.pc` on its own, and successful
detection relied on finding a non-BoringSSL copy, typically at a system
location (also fixed in ngtcp2 main branch).
Fix `ngtcp2_crypto_*` detections to not touch `PKG_CONFIG_LIBDIR` and
instead prepend `<path>` set via `--with-ngtcp2=` to `PKG_CONFIG_PATH`.
This ensures to pick up any dependent modules from system locations.
Note the side-effect is that potentially undesired modules may be
detected this way from system locations, i.e. it makes this particular
detection less "hermetic" than the rest used in curl configure.
(Configurations using a bare `--with-ngtcp2` with no path were not
affected, and served as a workaround before this patch. It remains a
valid way of configuration after.)
Both `pkgconf` and `pkg-config` use this logic to calculate their search
directory list:
```pseudo
search = {}
if PKG_CONFIG_PATH is set
search += PKG_CONFIG_PATH
endif
if PKG_CONFIG_LIBDIR is set (even if empty)
search += PKG_CONFIG_LIBDIR
else
search += built-in-pkg-config-dirs
endif
```
Refs:
https://github.com/curl/curl/pull/18028/commits (earlier attempt. Failed due to using `PKG_CONFIG_DIR` instead of the correct `PKG_CONFIG_PATH`)
https://github.com/curl/curl/pull/18028/commits/c0874ce8242d42a1ae1d570d6b70b8360da56482https://man.archlinux.org/man/pkgconf.1.enhttps://manpages.debian.org/unstable/pkgconf/pkgconf.1.en.htmlhttps://manpages.debian.org/unstable/pkg-config/pkg-config.1.en.html10e27fd63c
Bug: https://github.com/curl/curl/pull/18022#issuecomment-3120587041
Bug: https://github.com/ngtcp2/ngtcp2/pull/1689#issuecomment-3120593664
Follow-up to 04d90b5deb#20931
Follow-up to 3c64ffaff4#18415#18188
Follow-up to 99500660af#18028#18022Closes#20920
Configure LibreSSL autotools job with `--with-ngtcp=<path>` instead of
adding ngtcp2 to `PKG_CONFIG_PATH`. To test this way of configuration in
CI and test for the regression reported in #20889.
Turns out this way of configuration isn't affected by the detection
issue in this particular case.
It also works for other backends except for these two, subject to
separate fixes:
- BoringSSL fix: https://github.com/ngtcp2/ngtcp2/pull/2070
- GnuTLS fix and BoringSSL workaround: #20920
Follow-up to 666db80196#20891
Follow-up to 8db0e286b3#18189
Follow-up to 99500660af#18028#18022Closes#20926
To aid debugging cases when dependency detection acts unexpectedly.
Sprung from spending days trying to figure out behavior of ngtcp2 crypto
modules and their dependencies.
You can enable by setting env `CURL_TRACE_PKG_CONFIG` to a non-empty
value. When enabled, details are logged for both successful and
unsuccessful detections. Logging of unsuccessful ones is automatically
enabled when `CURL_CI` env is set, which is the case for all CI jobs.
It works by asking for `--debug` output and grepping for lines that seem
useful for this purpose. Output is different for classic pkg-config and
pkgconf, and may depending on tool version. Also append `--print-errors`
output if any.
Examples (with pkgconf):
Fail, before:
```
checking for libngtcp2_crypto_boringssl options with pkg-config... no
configure: error: --with-ngtcp2 was specified but could not find ngtcp2_crypto_boringssl pkg-config file.
```
Fail, after:
```
checking for libngtcp2_crypto_boringssl options with pkg-config... no
configure: pkg-config --exists libngtcp2_crypto_boringssl trace:
---- begin
trying path: /home/runner/nghttp3/build/lib/pkgconfig for libngtcp2_crypto_boringssl
trying path: /home/runner/ngtcp2-boringssl/build/lib/pkgconfig for libngtcp2_crypto_boringssl
trying path: /home/runner/nghttp3/build/lib/pkgconfig for libngtcp2
trying path: /home/runner/ngtcp2-boringssl/build/lib/pkgconfig for libngtcp2
trying path: /home/runner/nghttp3/build/lib/pkgconfig for openssl
trying path: /home/runner/ngtcp2-boringssl/build/lib/pkgconfig for openssl
trying path: /home/runner/nghttp2/build/lib/pkgconfig for openssl
==== error:
Package openssl was not found in the pkg-config search path.
Perhaps you should add the directory containing `openssl.pc'
to the PKG_CONFIG_PATH environment variable
Package 'openssl', required by 'libngtcp2_crypto_boringssl', not found
---- end
configure: error: --with-ngtcp2 was specified but could not find ngtcp2_crypto_boringssl pkg-config file.
```
Success, after:
```
checking for libngtcp2_crypto_boringssl options with pkg-config... found
configure: pkg-config --exists libngtcp2_crypto_boringssl trace:
---- begin
trying path: /home/runner/awslc/build/lib/pkgconfig for libngtcp2_crypto_boringssl
trying path: /home/runner/nghttp3/build/lib/pkgconfig for libngtcp2_crypto_boringssl
trying path: /home/runner/nghttp2/build/lib/pkgconfig for libngtcp2_crypto_boringssl
trying path: /home/runner/ngtcp2/build/lib/pkgconfig for libngtcp2_crypto_boringssl
trying path: /home/runner/awslc/build/lib/pkgconfig for libngtcp2
trying path: /home/runner/nghttp3/build/lib/pkgconfig for libngtcp2
trying path: /home/runner/nghttp2/build/lib/pkgconfig for libngtcp2
trying path: /home/runner/ngtcp2/build/lib/pkgconfig for libngtcp2
trying path: /home/runner/awslc/build/lib/pkgconfig for openssl
trying path: /home/runner/awslc/build/lib/pkgconfig for libssl
trying path: /home/runner/awslc/build/lib/pkgconfig for libcrypto
---- end
```
More examples:
https://github.com/curl/curl/pull/20926#issuecomment-4064259935
If there is an externally enablable, built-in feature like this in
classic pkg-config or pkgconf, I could not find it.
Also:
- GHA/http3-linux: set `CURL_TRACE_PKG_CONFIG` to log detection details.
H3 builds are prone to hard-to-debug dependency issues.
Ref: #20920
Follow-up to 3c64ffaff4#18415#18188
Follow-up to 99500660af#18028#18022
Cherry-picked from #20926Closes#20931
- 'badwords' is now a target in Makefile.am
- change badwords.txt to specify plain "words" instead of regexes so the
script can build single regexes when scanning, which makes the script
perform much faster (~6 times faster)
Closes#20869
To avoid potential warning with autotools when using `CFLAGS`. Existing
jobs are not affected.
Also:
- drop a redundant `export`.
- ensure not to overwrite per-job options with UWP ones.
Closes#20857
This CMake global custom option tells it to find dependencies as cmake
Configs first, and only then look for `Find*` modules. This may result
in `find_package()` succeeding, but without actually creating `CURL::*`
imported targets the curl build scripts are expecting.
For dependencies with curl-specific, local, `Find*` modules, we always
want to use them, via the module detection method, and never a
Config-based detection. Ensure this by passing the `MODULE` option to
`find_package()` and `find_dependency()` to make them use `Find*`
modules unconditionally, making them work as expected with the
`CMAKE_FIND_PACKAGE_PREFER_CONFIG=ON` option set.
curl uses local Find modules for all dependencies except OpenSSL and
ZLIB. The latter two keep using either CMake's built-in Find modules or
Config method as before this patch.
Also:
- apply the same change to `curl-config.cmake`. To fix consuming curl
with this option set.
Authored-by: Valerie Snyder
Ref: #20764
Follow-up to 16f073ef49#16973
- GHA/distcheck: add a job testing both building and consuming curl with
this option set. (takes 15 seconds)
Use custom NGHTTP2 configuration for an extra twist (not required
to trigger this issue.)
Follow-up to fcde8d7e37#20773
Reported-by: Valerie Snyder
Fixes#20729Closes#20784
- update action `actions/cache` from 5.0.1 to 5.0.3
- update action `github/codeql-action` from 4.31.9 to 4.32.4
- update pip `filelock` from 3.20.3 to 3.24.3
- update pip `ruff` from 0.14.14 to 0.15.2
Closes#20782Closes#20783
Adds 50 seconds to the 5m long build step. Also more prerequisites to
install, with no apparent effect on step time.
Follow-up to 9b52d516bb#20732Closes#20775
`scan-build` is a (Perl) wrapper around clang's built-in `--analyze`
option. Which look similar or identical to clang-tidy checkers under
the `clang-analyzer-*` namespace:
https://clang.llvm.org/docs/ClangStaticAnalyzer.html
Unless somebody has other information, it appears redundant to run
scan-build in parallel with clang-tidy in CI, now that the latter is
working reliably and with good performance for all curl components.
Another scan-build issue is the lack of a markup to suppress false
positives. It ignores `NOLINT`, yet finds the same false positives as
clang-tidy. This happens with scan-build v20+. v18 is silent, but it's
a blocker to upgrade to a newer version.
scan-build may still be a useful when combined with autotools, where
clang-tidy support is incomplete, slow (no parallelism), and uses
a distinct make target, which does not build binaries in the same pass.
But, scan-build also lacks extra checkers that are now enabled for
clang-tidy.
The clang-tidy job is also 30-40s faster than the one it replaced.
Also:
- drop scan-build job configured the same way as a clang-tidy one.
CI time saved: 6m30s
- bump to clang-20 (from 18) in the replacement job.
- build tests in the replacement job.
To verify a cmake command-line reconstruction issue only hit in this
job in CI.
CI time cost: 1m40s
- replacement job caught a minor, new, issue.
Ref: b2076d3c2f#20752
- drop unused scan-build logic.
Bug: https://github.com/curl/curl/pull/20732#issuecomment-3963873838
Ref: https://github.com/curl/curl/pull/20732#issuecomment-3967479228Closes#20751
Checking lib and src under 3m15s versus 7m15s.
Downside: autotools clang-tidy support is no longer CI-tested.
The reason for the slowness is invoking a single clang-tidy command with
all source files, and clang-tidy checking them in a single thread,
sequentially. clang-tidy offers a `run-clang-tidy` Python script for
parallel processing, which may help with this. However at this point
it's more practical to use cmake, which also supports verifying the
whole codebase, not only lib and src.
Also:
- bump clang-tidy to the latest available, v20 (from v18).
- enable running clang-tidy on tests. Takes under 2 minutes.
Also tried `_CURL_TESTS_CONCAT=ON`, it brings down the build tests step
from 1m47s to 54s, saving 1 minute. Skipped using it for now.
Closes#20725
Tests are build in "unity"-style, by including sources into an umbrella
C files (similar to how CMake unity works). This does not play well with
clang-tidy, which seems to unconditionally ignore C sources included
like this. To fix it, curl's CMake implements a manual clang-tidy
support for tests, which compiles sources one-by-one, while also making
sure sources compile cleanly standalone (e.g. all sources need to
include `first.h`). The manual clang-tidy implementation is fragile, and
performance, in particular when targeting Windows, is abysmal.
This patch introduces an alternate solution, enabled by the
`_CURL_TESTS_CONCAT=ON` option. In this mode, umbrella sources include
the actual sources instead of `#including` them. Allowing to use CMake's
built-in clang-tidy support to compile them, with clang-tidy actually
checking the sources. Making the manual clang-tidy support unnecessary.
In the Windows CI job it results in a 4x performance improvement (4m ->
1m), making it practical to run clang-tidy on tests on Windows, in CI.
The main downside is that clang-tidy doesn't understand the `#line`
directive. Meaning issues found show the wrong filename and line number
next to them. It's not impossible to locate errors this way, but also
not convenient.
Minor/potential downside is that the concatenated source needs to be
reassembled each time an original source is updated. This may result in
more copying on the disk when used in local development. The largest
source is 1.4MB, so probably not a show-stopper on most machines.
Another is the complexity of maintaining two methods in parallel, which
may be necessary till clang-tidy understands `#line`:
https://github.com/llvm/llvm-project/issues/62405
This solution may in theory also enable adding clang-tidy support for
tests in autotools, though I haven't tried.
Targeted for curl CI for now, and used in a GHA/windows job. 100%
experimental, not recommended outside these.
Closes#20667
Also:
- include code to verify a C++-specific public header regression
reported in 8.19.0-rc2.
- curl/curl.h: mention C++ global namespace in comment.
- GHA/dist: add CI job for C++. Runtime: 15 seconds.
Follow-up to ee9b000438#20686
Ref: #20682Closes#20687
