In both autotools and cmake builds, because Android does not offer
a `zlib.pc`.
Also:
- GHA/non-native: dump config files, to verify.
Reported-by: sfan5 on github
Fixes#21647Closes#21648
Exporting the component name as passed in is somewhat boring. OTOH it is
convenient for reuse.
- FindNGTCP2: export crypto backend in `NGTCP2_CRYPTO_BACKEND`.
- pass `COMPONENTS` `NGTCP2_CRYPTO_BACKEND` in `curl-config.cmake`.
- FindNGTCP2: fix to skip Config detection when optional `COMPONENTS` is
not passed.
Co-authored-by: Viktor Szakats
Reported-by: x-xiang on github
Fixes#21523
Follow-up to 8fce3e17e6#20814Closes#21540
To avoid (mis-)detecting it via the internal Apple library
`/usr/lib/system/libsystem_sim_kernel.dylib` when targeting iPhone
Simulator (seen with iPhoneSimulator26.4.sdk).
Reported-by: Ian Spence
Fixes#21236Closes#21271
Pass build options directly via `COMPILE_DEFINTIONS` and
`LINK_LIBRARIES`, instead of "tunneling" them through `CMAKE_FLAGS`.
The latter method breaks when passing `Threads::Threads` as library via
`CMAKE_REQUIRED_LIBRARIES`, while also being complex and fragile.
Example:
```
-- Performing Test HAVE_FSETXATTR_5
CMake Error at bld/CMakeFiles/CMakeTmp/CMakeLists.txt:27 (target_link_libraries):
Target "cmTC_3386e" links to:
Threads::Threads
but the target was not found. Possible reasons include:
* There is a typo in the target name.
* A find_package call is missing for an IMPORTED target.
* An ALIAS target is missing.
CMake Error at CMake/Macros.cmake:51 (try_compile):
Failed to generate test project build system.
Call Stack (most recent call first):
CMakeLists.txt:1684 (curl_internal_test)
```
Ref: https://github.com/curl/curl/actions/runs/23792043930/job/69329796592?pr=21168#step:38:318
Note: a side-effect is no longer passing C compiler flags (e.g.
`CMAKE_REQUIRED_FLAGS`) to the _linker_. This should not be an issue,
though CMake is passing them during its built-in detections.
Ref: https://cmake.org/cmake/help/v3.18/command/try_compile.htmlCloses#21176
Seen on macOS:
```
CMake Warning at CMakeLists.txt:2158 (message):
Bad lib in library list: Threads::Threads
```
Follow-up to 2d546d239e#21163Closes#21170
- use `Threads::Threads` imported target, replacing
`CMAKE_THREAD_LIBS_INIT`. To use the modern form and to allow using
`THREADS_PREFER_PTHREAD_FLAG` option.
- only add Threads library/options if POSIX Threads was detected (not
any other threading backend FindThreads may detect, e.g. the HP one.)
- curl-config.in.cmake: detect and define `Threads::Threads`.
Refs:
https://cmake.org/cmake/help/v3.18/module/FindThreads.htmlhttps://cmake.org/cmake/help/v4.3/module/FindThreads.htmlCloses#21163
Prior to this patch code used either `HAVE_PTHREAD_H`, or
`HAVE_THREADS_POSIX`, or both, to decide if POSIX Threads support is
present. In effect requiring both to be defined for a consistent build.
Drop detecting and guarding for `pthread.h`, and assume it present when
`HAVE_THREADS_POSIX` is set.
OS/400 had `HAVE_PTHREAD_H` set, but not `HAVE_THREADS_POSIX`, which
possibly left threading disabled in most sources.
Ref: https://pubs.opengroup.org/onlinepubs/009695399/basedefs/pthread.h.html
Ref: 930f2e8227#21144Closes#21158
Introduce `toolx_ftruncate()` macro and map it to existing replacements
for non-mingw-w64 Windows and DJGPP, or to `ftruncate` otherwise.
Follow-up to 6041b9b11b#21109Closes#21130
Build with "configure --enable-init-mem-debug" to make the tool use
curl_global_init_mem() and a set of private memory funtion callbacks for
libcurl's memory management.
Using this setup, memory mixups in tool code is more likely to cause
crashes and thus get discovered while running tests.
This curl_global_init_mem debug mode can only be done when building
libcurl shared (not static) and without debugging enabled - since it
needs to use the custom memory funtion callbacks.
Closes#21099
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
Replace the `volatile int dirty` with a reference counter
protected by a mutex when available.
Solve the problem of when to call application's lock function
by adding a volatile flag that indicates a share has been added
to easy handles in its lifetime. That flag ever goes from
FALSE to TRUE, so volatile might work (in the absence of a mutex).
(The problem is that the lock/unlock functions need 2-3
`curl_share_setopt()` invocations to become usable and there
is no way of telling if the third will ever happen. Calling
the lock function before the 3rd setopt may crash the
application.)
When removing a share from an easy handle (or replacing it with
another share), detach the easy connection on a share with a
connection pool.
When cleaning up a share, allow this even if it is still used in
easy handles. It will be destroyed when the reference count
drops to 0.
Closes#20870
- it was already required for `curl_*printf()` float/double support.
- some curl tests always fail without it.
- it was already assumed to be present to build test servers.
Source code did not check for `HAVE_SNPRINTF` detection variable.
- it was already required to build examples.
Windows builds stopped using this detection and the function via earlier
commits.
Follow-up to 64f28b8f88#20765
Follow-up to 935b1bd454#9570#9569Closes#20763
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
Instead hook up the upstream target name as-is to the local wrapper
target.
To:
- make the hack work regardless of how the upstream target was created.
- make it work the same way in `curl-config.cmake`.
Before this patch it had no guard for `IMPORTED` targets even though
`find_dependencies()` is not guaranteed to create the target expected
if it already existed and was potentially created differently.
Depends-on: #20840
Follow-up to 4f1646ef8a#20486#20419Closes#20839
To allow simplifying the binutils ld hack, by chaining the original
imported target to curl's local duplicate target. Also to allow linking
to dependencies' native imported targets via their CMake Configs, which
will always be hooked up to a `CURL::` interface, and may also be
chained upstream.
Fixing (seen on Linux with simplified binutils hack via #20839):
```
Requires:
Requires.private: libzstd openssl zlib
Libs: -L${libdir} -lcurl
-Libs.private: -lcrypto -lssl -lz -lzstd
+Libs.private: -lOpenSSL::Crypto -lZLIB::ZLIB -lcrypto -lssl -lz -lzstd
Cflags: -I${includedir}
Cflags.private: -DCURL_STATICLIB
Error: Process completed with exit code
```
Ref: https://github.com/curl/curl/actions/runs/22768301699/job/66041980258?pr=20839
Note this makes it possible to run into an infinite loop because CMake
allows cyclic dependencies. It isn't added by curl's CMake script nor by
any dependencies as defined by default, but may happen in theory with
custom-created targets. In such case CMake automatically stops with
an error at 1000 iterations. I find it overkill to add custom protection
for it.
Cherry-picked from #20814
Cherry-picked from #20839Closes#20840
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
To fix building tests/server with cmake and both wolfSSL and OpenSSL
enabled (MultiSSL).
tests/server do not have libcurl dependency header paths setup because
it does not use libcurl. The code however includes `curl_setup.h`, which
tried including `wolfssl/version.h` before this patch to verify if the
wolfSSL coexist feature is available. Without a header path, it failed:
```
In file included from bld/tests/server/servers.c:3:
In file included from tests/server/first.h:40:
lib/curl_setup.h:737:12: fatal error: 'wolfssl/version.h' file not found
737 | # include <wolfssl/version.h>
| ^~~~~~~~~~~~~~~~~~~
1 error generated.
```
Ref: https://github.com/curl/curl/actions/runs/22410066319/job/64880787424#step:46:76
Fix by moving the include and version check to `vtls/wolfssl.c`.
Also: add an early version check to cmake.
Follow-up to 16f073ef49#16973
Cherry-picked from #20720Closes#20726
- vms/curlmsg_vms.h: delete unused/commented code.
- vtls/schannel_verify: sort includes.
- typecheck-gcc.h: fix indent and alignment.
- lib/config-win32.h: drop idle `#undef`.
- spacecheck: check for stray empty lines before after curly braces.
- make literals more readable: 1048576 -> 1024 * 1024
- scope variables.
- use ISO date in a comment.
- drop redundant parentheses.
- drop empty comments.
- unfold lines.
- duplicate/stray spaces in comments.
- fix indent, whitespace, minor typos.
Closes#20690
Instead of globally disabling unity for all targets when clang-tidy is
enabled.
After this patch `CMAKE_UNITY_BUILD=ON` is honored for:
- static libcurl when building both static and shared separately.
- libcurlu and libcurltool internal libraries when building the test
target.
While keeping unity disabled for the libcurl build pass running
clang-tidy, and the curl tool, also running clang-tidy.
To make clang-tidy-enabled builds finish faster when unity mode is
enabled, yet performs the same clang-tidy checks as before this patch.
Effect on:
- GHA/macos: core build: same, buils tests 5-12 seconds faster,
with steps going down from 259 to 25.
52s: https://github.com/curl/curl/actions/runs/22279958340/job/64448913325 ->
47s: https://github.com/curl/curl/actions/runs/22279873606/job/64448710743
- GHA/windows (not enabled): it'd save about 1 minute, bringing total
time barely below 10m, still one of the slowest jobs overall.
(#20667 is trying a way for 4x speed-up (with a drawback)).
5m21s: https://github.com/curl/curl/actions/runs/22222907068/job/64284556852 ->
4m26s: https://github.com/curl/curl/actions/runs/22281033369/job/64451601548Closes#20670
Fix bigger and smaller kinks in how clang-tidy is configured and used.
Sync behavior more between autotools and cmake, lib/src and tests. Bump
clang-tidy minimum version and prepare logic to allow using clang-tidy
to a fuller extent.
- move clang-tidy settings from builds to a new `.clang-tidy.yml`.
To make it easy to see and edit checks at one place. Also to allow
using the `--checks=` option internally to silence tests-specific
checks. (clang-tidy does not support multiple `--check=` options via
the command-line.)
Use explicit `--config-file=` option to point to the configuration.
- .clang-tidy.yml: link to documentation.
- suppress `clang-diagnostic-nullability-extension` due to a false
positive in libtests with `CURL_WERROR=ON` and `PICKY_COMPILER=OFF`.
- .clang-tidy.yml: enable `portability-*`, `misc-const-correctness`.
- drop `--quiet` clang-tidy option by default to make its working a bit
more transparent. The extra output is minimial.
- consistently use double-dashes in clang-tidy command-line options.
Supported by clang-tidy 9.0.0+ (2019-09-19). Before this patch single
and double were used arbitrarily.
- src/tool_parsecfg: silence false positive `clang-analyzer-unix.Stream`.
Seen with clang 18 + clang-tidy 19 and 20 (only with autotools.)
- INTERNALS: require clang-tidy 14.0.0+. For the `--config-file` option.
- INTERNALS: recommend clang-tidy 19.1.0+, to avoid bogus
`clang-analyzer-valist.Uninitialized` warnings. (bug details below)
autotools:
- allow configuring the clang-tidy tool via `CLANG_TIDY` env.
Also to use in GHA to point to a suffixed clang-tody tool.
- fix to pass CFLAGS to lib, src sources.
(keep omitting them when using a non-clang compiler.)
- fix to pass `--warnings-as-errors=*` in quotes to avoid globbing.
cmake:
- fix to not pass an empty `-I` to clang-tidy.
- fix to pass CFLAGS (picky warnings) to clang-tidy for test sources.
(keep omitting them when using a non-clang compiler.)
- fix to disable `clang-diagnostic-unused-function` for test sources.
(tests have static entry points, which trigger this check when
checking them as individidual sources.)
- fix forwarding `CURL_CLANG_TIDYFLAGS` to clang-tidy.
- force disable picky warnings when running clang-tidy with a non-clang
compiler. To not pass these flags when checking lib and src.
CI:
- GHA/linux: avoid clang-tidy bug by upgrading to v19, and drop the
workaround.
- GHA/linux: switch to clang from gcc in the clang-tidy job. Using gcc
doesn't allow passing CFLAGS to clang-tidy, making it less effective.
(My guess this was one factor contributing to this job often missing
to find certain issues compared to GHA/macos.)
I recomment using clang-tidy with a clang compiler, preferably the same
version or one that's compatible. Other cases are best effort, and may
fail if a C flag is passed to clang-tidy that it does not understand.
Picky warnings are mostly omitted when using a non-clang compiler,
reducing its usefulness.
Details and reproducer for the v18 (and earlier) clang-tidy bug,
previously affecting the GHA/linux job:
clang-tidy <=18 emits false warnings way when passing multiple C sources
at once (as done with autotools):
```sh
cat > src1.c <<EOF
#include <string.h>
static void dummy(void *p) { memcmp(p, p, 0); }
EOF
cat > src2.c <<EOF
#include <stdarg.h>
void vafunc(int option, ...)
{
va_list param;
va_start(param, option);
if(option)
(void)va_arg(param, int);
va_end(param);
}
EOF
/opt/homebrew/opt/llvm@18/bin/clang-tidy --checks=clang-analyzer-valist.Uninitialized src1.c src2.c
# src2.c:7:11: warning: va_arg() is called on an uninitialized va_list [clang-analyzer-valist.Uninitialized]
```
Follow-up to e86542038d#17047Closes#20605
- fix internal macro `AN_APPLE_OS` reused between sources without
resetting it. It may potentially have left the system sha256
function unused.
- fix to define `WOLFSSL_OPTIONS_IGNORE_SYS` so that it always applies
to wolfSSL headers, also during feature detection.
- md4, md5, sha256: simplify fallback logic.
- delete 20+ unused macros.
- scope or move macros to avoid `-Wunused-macros` warnings.
- examples: delete unused code.
The warning detects macros defined but not used within the same C
source. It does not warn for macros defined in headers. It also works
with unity builds, but to a lesser extent.
Closes#20593
The change was valid, but caused an annoying warning with perfectly
working non-binutils ld linkers:
```
ld: warning: ignoring duplicate libraries: 'my/path/usr/local/lib/libcrypto.a'
```
(seen with Apple clang, when using static `libcrypto.a`)
It means that for the binutil ld hack to work at consumption-time, curl
must be built with the same picky binutils (gcc) toolchain.
Reverts 795433b923#20434Closes#20594
To simplify setting BoringSSL version, using:
`-DBORINGSSL_VERSION=0.20260211.0`
or
`-DBORINGSSL_VERSION=${boringssl_version}`
Previously it could be set via C flags, using complicated shell quotes:
`-DCMAKE_C_FLAGS="-DCURL_BORINGSSL_VERSION=\\\"${boringssl_version}\\\""`
(the C flags method remains, also for autotools)
It'd be nice if BoringSSL published its version not just via
`MODULE.bazel` in its source tree, but from its public headers, to make
these workarounds unnecessary.
Also:
- GHA/http3-linux: test both options.
Closes#20571
- move macro to `curl_setup.h` (from curlx), and rename.
It's required by src, test servers, libtests. Also used by unit/tunit,
(which is fixable but this patch doesn't touch it.)
- special-case it for Windows/Cygwin/MS-DOS.
- build: drop `setmode()`/`_setmode()` detection.
This also avoids detecting the different `setmode()` on BSDs,
and a lot of complexity and overhead.
- use `CURL_O_BINARY`.
Follow-up to 250d613763#15787
Follow-up to 5e70566094#15169Closes#20539
