- set `CURL_DROP_UNUSED=ON` for Windows (MSVC) to make the analysis step
faster: 1m30s -> 1m15s
- enable `CURL_WERROR=ON` in all builds, to catch potential build issues
in addition to running CodeQL. To make these builds useful as regular
build tests too.
- add links to CodeQL Actions documentation.
- delete test data C files after checkout in an attempt to remove them
from CodeQL code coverage stats.
Closes#20418
Replace Chocolatey install with direct download and unpack. To reduce
CI dependencies (Chocolatey, NuGet), improve install performance
(10s -> 1s) and hopefully reliability. Last but not least to enable it
for the Cygwin CI job.
Caveats:
- Need to bump stunnel versions manually (2-3 times a year).
Renovate could likely do it, but I failed to understand its
documentation and miss tooling/interface to make tests.
- FIPS not enabled. (can be done if necessary)
- Possibly losing checksum verification (not sure if Chocolatey did it
automatically for this package.)
Also:
- Increase minimum tests by 100 for the Cygwin job.
Ref: #16819 (earlier attempt)
Ref: https://www.stunnel.org/archive/
Ref: https://www.githubstatus.com/incidents/cqb5hcy0gx18
Follow-up to d176f58a2003e4231c75f09813125c5a5bb26913 #20413
Follow-up to 19b1e44660d68d38a2f48f24740a3aac1d46b9a0 #20409Closes#20410
Before this patch CI silently ignored stunnel install failures. This
pushed the failure to the test run step due to not meeting the minimum
number of tests.
Make the root cause obvious by failing early in this case.
Reported-by: Stefan Eissing
Follow-up to 3f1cd809eeae05f39fec72fe780f3a69d21972fb #19942
Ref: https://github.com/curl/curl/actions/runs/21245626382/job/61134101176?pr=20397
Ref: #16819Closes#20409
Bump CMake version in CMake integration tests for better performance
(8x on macOS, 2-3x on Windows) and native arm64 binaries.
- bump old CMake in integration tests to v3.19.8 (was: v3.11.4)
- switch to native arm64 CMake binaries on macOS.
- switch Linux CMake integration job to arm64.
Speed gains:
- Linux: 2m -> 1m30s
- macOS: 9-10m -> 1m15s
- Windows: 6-7m -> 2m43s
Before:
https://github.com/curl/curl/actions/runs/21255697172https://github.com/curl/curl/actions/runs/21255020621
After:
https://github.com/curl/curl/actions/runs/21272021446
With this, CI is:
- no longer testing deprecated CMake versions.
Follow-up to a7c974e038572bd1d4a653afbd6de5fad5a10215 #19902
- not testing the next (from 2026 April) minimum 3.18, but going for
3.19 instead. For arm64 binaries on both macOS and Linux. There is
no 3.18-specific CMake code in curl.
Cherry-picked from #20407Closes#20408
To avoid unnecessarily installing Intel C for any `<pkg>-intel` locally
built dependency.
Follow-up to ab8ccaed2479bf7d019b3aa25f22299546e23828 #20392
Follow-up to d9fe60d4572bf82e407ae33277f81def896d06f2 #20248Closes#20400
To enable known linker options dropping unused, dead, code and data from
the executables built.
Useful to reduce binary sizes for curl, libcurl shared lib and apps
linking static libcurl. It's effective on both "unity" and non-unity
builds. Aligning "unity" build sizes with default, non-unity ones.
Supported platforms: Apple, MSVC, llvm/clang and GCC on all tested
platforms: Linux, BSDs, Windows, MSYS2/Cygwin, Android, MS-DOS.
Notes:
- Static libraries grow 20-30% with non-Apple toolchains.
This effect is controlled by separate, optional compiler flags on
non-Apple. This patch enables them automatically for public binaries
(libcurl and curl tool), and leaves them off for internal/test ones.
- MSVC enables this option by default for 'Release' configurations.
The curl build option has no effect on it.
- Observed effect on VS2010 is negligible. VS2012+ is recommended.
- Works with LTO, Fil-C.
- No observed/conclusive effect on build speed.
- On Windows with clang/gcc (mingw-w64/MSYS2/Cygwin) it also enables
`-fno-asynchronous-unwind-tables` as a workaround to make
the toolchain options actually work.
Ref: https://sourceware.org/bugzilla/show_bug.cgi?id=11539
Thanks-to: Andarwinux
Also:
- GHA: enable in Linux and MinGW jobs to test it. Size changes:
- linux aws-lc H3:
curl: 2000000 -> 1937152, libcurl.a: 2065724 -> 2716532 bytes
- macos clang HTTP-only:
curl: 1364376 -> 128799 bytes, libcurl.a: unchanged
- macos llvm MultiSSL:
curl: 410056 -> 405720, libcurl.dylib: 1350336 -> 1348480 bytes
- mingw schannel c-ares U:
curl: 1588736 -> 1507328, libcurl-d.a: 3322040 -> 3884746 bytes
bld: 34 -> 35MB
- GHA: enable in MSVC and Apple jobs to reduce disk footprint, with no
obvious downside. Size changes:
- AppVeyor CI VS2019:
curl: 2339840 -> 1295872, libcurl-d.dll: 3155968 -> 1900544 bytes
bld: 161 -> 97MB
- AppVeyor CI VS2022 clang-cl:
curl: 2933248 -> 2332160, libcurl-d.lib: 4762688 -> 5511330 bytes
bld: 133 -> 121MB
- AppVeyor CI VS2022 HTTP-only:
curl: 3514368 -> 2177024, libcurl-d.lib: 2538420 -> 3151740 bytes
bld: 137 -> 83MB
- GHA intel:
curl: 2629120 -> 2023424, libcurl-d.lib: 4366652 -> 5350670 bytes
bld: 86 -> 69MB
- GHA arm64:
curl: 2832896 -> 2063872, libcurl-d.lib: 4690616 -> 5597250 bytes
bld: 82 -> 66MB
Refs:
https://maskray.me/blog/2021-02-28-linker-garbage-collectionhttps://web.archive.org/web/20110811230637/msdn.microsoft.com/en-us/library/bxwfs976.aspx (VS2010)
https://learn.microsoft.com/cpp/build/reference/opt-optimizationshttps://learn.microsoft.com/cpp/build/reference/gy-enable-function-level-linkingCloses#20357
Unstripped size hides effective binary sizes due to the added debug
information. E.g. `--gc-sections` may inflate unstripped binaries, while
their unstripped size decreases. To see if binary size optimization
options work, it's more useful to observe unstripped size.
Ref: #20357
Follow-up to 4cf43508e8e60d0d8acef1beecb0f76040609543 #20355Closes#20359
- schannel: fix mixed-up declaration. (originally fenced infof for
verbose, then changed to failf with the fence kept, then fence
removed and variable marked as verbose, when in fact it's not, but
not tested and caught in CI.
- fix two other fallouts.
- GHA/windows: disable verbose strings in a mingw job.
- appveyor: disable verbose strings in an MSVC job.
- appveyor: add way to pass any CMake option per-job.
Cherry-picked from #20387
Follow-up to 61093e2a819d26b7ddf309baef264b9e50c6c56f #20353Closes#20388
When the compiler supports C99.
- map logging functions to macro stubs when verbose logging is disabled
and the compiler is C99. Make sure these stubs silence unused variable
warnings for non-variadic arguments.
Before this patch they mapped to function stubs, the same codepath
used for C89 compiler in this configuration.
- introduce new macros to tell the compiler which code to include
when verbose code is active, or inactive:
- `CURLVERBOSE`: defined when verbose code is active.
To enclose blocks of code only used for verbose logging.
- `VERBOSE(statement);`:
compile statement when verbose code is active.
To mark code lines only used for verbose logging.
- `NOVERBOSE(statement);`:
compile statement when verbose code is inactive.
To suppress warnings for arguments passed to logging functions via
printf masks, e.g. `NOVERBOSE((void)ipaddress);`, yet keeping
the warning in verbose builds.
Note these macros are not the same as `CURL_DISABLE_VERBOSE_STRINGS`.
Verbose code is always active in C89 mode (without variadic macro
support).
- drop existing uses of `CURL_DISABLE_VERBOSE_STRINGS` where redundant,
or replace with the above macros. Ending up reducing the number of
`#ifdef`s, and also the number of lines.
Assisted-by: Daniel Stenberg
Assisted-by: Jay Satiro
Reported-by: Dan Fandrich
Fixes#20341
Refs: #12105#12167Closes#20353
- `stdbool.h` is also included via system headers. Disabling it from curl
does not fix it. Silencing lots of these:
```
curl/lib/curlx/warnless.h:64:1: warning: '_Bool' is a C99 extension [-Wc99-extensions]
64 | bool curlx_sztouz(ssize_t sznum, size_t *puznum);
| ^
/Library/Developer/CommandLineTools/usr/lib/clang/17/include/stdbool.h:24:14: note: expanded from macro 'bool'
24 | #define bool _Bool
| ^
```
- silence `-Wcomma` warnings.
in favor of the global silencing approach, since a couple of more of
these were hit (in vquic, tool1622, unit1309, unit1636), and it seems
silly to update them all.
Revert e8189c44201db6bff987a8771df90f853d93dec5 #20362
Also:
- cmake: include C standard in 'platform flags' log line.
- GHA/macos: switch a job to C89 to verify.
- GHA/linux: show 'C89' in job names.
Ref: https://cmake.org/cmake/help/v3.7/variable/CMAKE_C_STANDARD.htmlCloses#20363
Drop separate `TrackMemory` (aka `CURLDEBUG`) debug feature.
After recent changes (thread-safety,
193cb00ce9b47e75d42157c650cc3de3fd96d35d, and updates leading up to
it), `TrackMemory` is unlikely to cause build or runtime issues.
To simplify builds and debug options, enable `TrackMemory`
unconditionally for debug-enabled (aka `DEBUGBUILD`) builds. Before
this patch, this was already the default, with an option to disable
it, or enable it in non-debug-enabled builds.
Note, in practice these two debug options already went hand in hand. It
was not possible to toggle them separately for a long time due to bugs,
before 59dc9f7e69c399102e9ebe3670360ef52706ff23 (2024-05-28) fixed it.
This patch also removes/deprecates separate knobs and feature flags for
`TrackMemory`:
- autotools: `--enable-curldebug`/`--disable-curldebug`
- cmake: `-DENABLE_CURLDEBUG=ON`/`OFF`
- C macro: `CURLDEBUG`
- libcurl: `CURL_VERSION_CURLDEBUG` symbol deprecated in favor
of `CURL_VERSION_DEBUG`. They always return the same value after this
patch.
Also:
- drop `TrackMemory` from `curl -V` output.
- rename internal `CURLDEBUG` macro to `CURL_MEMDEBUG` internally.
To avoid confusion with `DEBUGBUILD`, but to keep guarding
`TrackMemory`-related internals for readability.
- runtests: bind `TrackMemory` to debug feature. Keep it a separate
test feature requirement, for clarity.
- CI: drop test builds for combinations of the two options.
- GHA/linux: no longer disable TrackMemory in the TSAN job.
Ref: https://github.com/curl/curl/pull/20328#issuecomment-3754528407Closes#20331
- It is slower and uses more memory than the alternatives and is only
experimental in curl.
- We disable a few tests for OpenSSL-QUIC because of flakiness
- It gets little attention from OpenSSL and we have no expectation of the
major flaws getting corrected anytime soon.
- No one has spoken up for keeping it
- curl users building with vanilla OpenSSL can still use QUIC through the
means of ngtcp2
Closes#20226
With the same semantics as Apple SecTrust, in both libcurl and the curl
tool, when using non-Schannel TLS backends. In practice it means that
it makes TLS work without manually or implicitly configuring a CA bundle
`.crt` file, such as `curl-ca-bundle.crt`.
To enable:
- autotools: `--enable-ca-native`
- cmake: `-DCURL_CA_NATIVE=ON`
- CPPFLAGS: `-DCURL_CA_NATIVE`
When enabled:
- enables `CURLSSLOPT_NATIVE_CA` (libcurl) / `--ca-native`
and `--proxy-ca-native` (curl tool) options by default.
- unsafe search for an on-disk CA bundle gets disabled by default.
Equivalent to `--disable-ca-search` with autotools,
`-DCURL_DISABLE_CA_SEARCH=ON` with CMake.
- build-time detection of CA bundle and CA path gets disabled. As with
Apple SecTrust. This was already the default for Windows.
- native CA can be disabled at run-time with the `--no-ca-native`
and/or `--no-proxy-ca-native` command-line options.
Rationale: This build option:
- has a repeat and active interest from packagers and users.
- helps integrating curl with Windows for those who need this.
- it also applies to macOS: #17525
Shipped in curl 8.17.0.
- makes it trivial to use custom certs configured on the OS.
- frees applications/packagers/users from the task of securely
distributing, and keeping up-to-date, a CA bundle.
- frees potentially many curl tool from configuring a CA bundle manually
to access HTTPS (and other TLS) URLs. This is traditionally difficult
on Windows because there is no concept of a universal, protected,
non-world-writable, location on the file system to securely store
a CA bundle.
- allows using modern features regardless of Windows version. Some of
these features are not supported with Schannel (e.g. HTTP/3, ECH) on
any Windows version.
- is necessary for HTTP/3 builds, where bootstrapping a CA bundle is not
possible with Schannel, because MultiSSL is not an option, and HTTP/3
is not supported with Schannel.
Ref: #16181 (previous attempt)
Ref: https://github.com/curl/curl/discussions/9348
Ref: https://github.com/curl/curl/issues/9350
Ref: https://github.com/curl/curl/pull/13111
Ref: https://github.com/microsoft/vcpkg/pull/46459#issuecomment-3162068701
Ref: 22652a5a4cb6a4cc1c0f4ff3ebc4f9768f6663cd #14582
Ref: eefd03c572996e5de4dec4fe295ad6f103e0eefc #18703Closes#18279
After this patch curl requires targeting Vista or newer, and a toolchain
with Vista support.
Supported MSVC compilers (VS2010+) all support Vista:
- VS2012+ target Win8 (or later) by default.
- VS2010 targets Win7 by default.
Supported mingw-w64 versions (v3+) all support Vista:
- mingw-w64 v9+ target Win10 by default.
- mingw-w64 v8 and older target Server 2003 (~XP) by default.
After this patch it may be necessary to override the default Windows
target version to Vista (or newer) via:
autotools: `CPPFLAGS=-D_WIN32_WINNT=0x0600`
cmake: `-DCURL_TARGET_WINDOWS_VERSION=0x0600`
- mingw-w64 v6+ allow changing the default at toolchain build-time.
Notes:
- For non-MSVC, non-mingw-w64 toolchains, `if_nametoindex` needs to be
allowlisted in `curl_setup.h`, if they do support it.
Fixes#17985 (discussion)
Closes#18009
- MSYS2/Cygwin bash shells are now tagged "misfeature".
It is not something we can fix. We need these shells, and using
documented/necessary settings to use these environments should be
allowed without workarounds.
- untagged actions within curl's own organization are now also flagged
as "action is not pinned to a hash (required by blanket policy)". This
seems overkill. Making internal releases would not be helpful or
practical. Also considering that the referred internal action uses an
unpinned external action anyway (google/oss-fuzz/infra/cifuzz), with
near-zero chance to fix.
Ref: https://github.com/zizmorcore/zizmor/pull/1517#issuecomment-3759740853Closes#20339
To simplify the directory layout.
- OS400 and vms support move from `packages` to `projects`.
- Windows README and `generate.bat` files move from `projects`
to `projects/Windows`.
Closes#20271
To run checksrc and spacecheck on the source tree. Also for cmake
to sync up with autotools' `checksrc` target.
- cmake: `curl-lint`
With `-DCURL_LINT=ON`, checks run automatically for all targets.
- autotools: `lint`
Closes#20175
CI workflows deleted apt package source `microsoft-prod.list` due to
flakiness seen in the past with those sources. Sources are still flaky
and they are now also used from `azure-cli.sources` which is included
by default by the runner images. Add it to the delete list.
Also: remove another new, unnecessary (for curl CI) package source seen
on the `ubuntu-24.04-arm` runner, for good measure, and performance.
Fixing:
```
Reading package lists...
E: Failed to fetch https://packages.microsoft.com/repos/azure-cli/dists/noble/InRelease 403 Forbidden [IP: 13.107.246.66 443]
E: The repository 'https://packages.microsoft.com/repos/azure-cli noble InRelease' is no longer signed.
Error: Process completed with exit code 100.
```
Ref: https://github.com/curl/curl/actions/runs/20896127602/job/60034941964?pr=20142#step:2:79
Follow-up to 303bb8785c45fcad879c9c1c86e9c7e09ff68097 #13473Closes#20253
Turns out in practice the internal cache name contains the arch where it
matters (arm or dual-arch local builds), which is part of the cache key
string. Drop `runner.arch` to avoid two arch strings in the key.
Cache keys without an explicit arch designator mean intel.
Revert ff78af5752fdf580e5beef743f932cc1625228c3 #20234Closes#20249
`mbedtls-arm` and `mbedtls-prev` were matching `contains()` expressions
looking for `mbedtls`. It caused an unnecessary cache restore and an
redundant mbedtls build on bumps, and made the build flavors require
different local directory names to avoid this accidental collision.
Also drop `-threadsafe` from internal names. All local builds are.
Follow-up to 88060353440df4e1b7167c180b39074fd2ab457a #20240
Follow-up to 3a305831d1a9d10b2bfd4fa3939ed41275fee7f7 #19077Closes#20248
All libresll jobs, wolfssl-all, and one mbedtls job.
As noted earlier, arm jobs run faster than intel ones, especially
valgrind steps that run almost twice as fast. Package install runs
slower, but this is offset by faster build and test steps, even in
non-valgrind jobs.
Follow-up to ff78af5752fdf580e5beef743f932cc1625228c3 #20234
Follow-up to 2b0d8dcc16c531d3154ab54347a3eaabf9bd2c7d #20231Closes#20246
`libressl-filc` was matching `contains()` expressions looking for
`libressl`, causing build confusion and failure in specific cases.
Rename `libressl` to `libressl-c` to avoid this. Also rename the cache
id for consistency, though not necessary for the fix.
Bug: https://github.com/curl/curl/actions/runs/20860412340/job/59938315276
Follow-up to c2624818739916652a041164939afaba5bb5ee73 #19407
Cherry-picked from #20234Closes#20240
More cost-effective and seems as fast or faster than Intel.
In particular, valgrind seems to be almost 2x fast. So fast the job pair
could fit under 10 minutes if merged again (but would be the longest in
GHA/Linux.)
Installing packages is slightly slower. The package repo is Ubuntu's
which is slower than the Azure mirror used on Intel (unless Azure is
broken, which happened a lot last year).
To add to more jobs, the locally built deps also need to be migrated.
Also:
- add workaround for failing sshd server on Linux arm runners, caused by
world-writable `HOME` directory.
Closes#20231
To:
- see if build tool makes a difference for flaky 8x pytest slowdowns.
- to make this job finished faster.
`curl -V`, number of runtests (1793) and pytests (568/159) verified
to remain the same.
Closes#20211
In `!ssl` variant.
It's useful to catch `uint32_t` mismatches with `unsigned int` or its
printf mask.
Also add Renovate version bump rule.
It takes about 1m (autotools) + 30s (cmake) in CI.
Bug: https://github.com/curl/curl/pull/20199#discussion_r2666363334
Follow-up to 8881a52ab0bc7f8cdaad3161e189570d69f0cd3c #20210
Follow-up to e70436a88a7ba16f6a49237054dde41f181fd9c4 #20200
Follow-up to 0630e66cb4044892ec137c3357852fe025746f35 #18338Closes#20204
Number of jobs down to 34 (from 56 at end of last year.)
Out of them 7 autotools (was 24 at end of last year.)
Also:
- stop install brew packages preinstalled.
- make some dependency options explicit.
Closes#20203
To save 0.5 to 3 minutes per job.
There remain 7 main autotools jobs, plus 1 in combinations and 1 more
for iOS.
Also:
- fix to disable MQTT, WebSockets, IPFS in HTTP-only job.
Closes#20193
To reduce the number of jobs, and the time spent running macos runners.
The curl codebase has just a few Apple-specific parts, and they remain
well-covered after this patch.
Makes the number of jobs 24, down from 32.
Perhaps more jobs could be merged or dropped, and CPU use reduced by
moving some to cmake. Unique, but not Apple-specific jobs may also be
moved to Linux.
Follow-up to b869932392512d1c3a4d5396361f9acdd110ba4b #20178Closes#20187
- drop autotools (except one) from combination jobs.
They seem to add little value over cmake ones, yet take a lot of time
even after restricting them to shared libs.
20-25s to install autotools via Homebrew, for each 11 jobs. autoreconf
taking 10s, configure 25s, build 30-35s. A total of 1m30s to 1m45s per
job. Sometimes jumping up to 2-4 minutes.
Compare this to 20-25s total job times with cmake.
Keep one job with an indentical cmake pair to help detecting
build-tool-specific fallouts.
- drop more combination jobs.
To avoid overlap with main build jobs.
Reducing number of jobs to 9, from 22 (-13),
total job time to 5.5 minutes, from 25 (-20m).
Before: https://github.com/curl/curl/actions/runs/20637652089
After: https://github.com/curl/curl/actions/runs/20686390641?pr=20178
Considering the small amount of Apple-specific code in curl since
dropping Secure Transport, and that most combination issue were in
the toolchains, not curl, there is likely more room to avoid wasting
cycles (at 41 macOS + 3 iOS jobs after this patch).
Follow-up to d057b705fdb44b2df99ce6fc6ffb8f2a3530755a #20167Closes#20178
