For DragonFlyBSD and SunOS.
Also opt-in `BSD`, which is covering those listed explicitly, when using
CMake 3.25+.
Follow-up to 131a2fd5aa#16987Closes#21243
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
- 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
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
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
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
- 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
Extend `#pragma diagnostic push`/`pop` guards to the whole codebase
(from tests and examples only) to disable it for GCC <4.6. Rename guard
to `CURL_HAVE_DIAG` and make it include llvm/clang to be interchangeable
with `__GNUC__ || __clang__` in this context.
The above means no longer disabling certain warnings locally, so pair
this with disabling all picky warnings for GCC <4.6.
Also:
- drop global workarounds for misbehaving GCC <4.6 compiler warnings.
Not needed with picky warnings disabled.
Reported-by: fds242 on github
Reported-by: Sergey Fedorov
Thanks-to: Orgad Shaneh
Follow-up to f07a98ae11#20366Fixes#20892Fixes#20924Closes#20902Closes#20907
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
It's mostly a filler word. I've read through each use of it in the code
base and did minor rephrasings when "simply" carried some meaning. The
overwhelming majority of cases, removing it improved the text
significantly. Inspired by #20793.
Closes#20822
- also query `INTERFACE_COMPILE_DEFINITIONS` and
`INTERFACE_COMPILE_OPTIONS`.
To further sync clang-tidy manual command-lines with the C compiler
command-lines generated by CMake. In practice this adds `-I` options
(via `INTERFACE_COMPILE_OPTIONS`) to the end of the command-line for
dependency header directories. It does not change the outcome of
clang-tidy runs.
- limit querying `COMPILE_DEFINITIONS` and `COMPILE_OPTIONS` to the top
target, the test itself. To not include options such as
`-DCURL_HIDDEN_SYMBOLS` and `-fvisibility=hidden` (when set) via
the libcurl shared lib.
To sync with the actual C compiler command-line.
- drop redundant `unset()`.
- rename local function to be more specific.
Follow-up to d9386a2f8e#20759Closes#20829
Exclude reading certain props for certain target types to avoid these errors:
```
CMake Error at CMake/Utilities.cmake:71 (get_property):
The LOCATION property may not be read from target "...". Use the target
name directly with add_custom_command, or use the generator expression
$<TARGET_FILE>, as appropriate.
```
(and the same in line 78.)
Follow-up to 855acb3bb0#17701Closes#20828
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
I thought a macro is necessary to have `get_directory_property()` and
`CMAKE_CURRENT_SOURCE_DIR` work on the correct directory, but it turns
out they do work the same when used in a function.
Closes#20760
To avoid a system include masking a custom directory, and e.g. picking
up system OpenSSL headers from `/usr/include` on Linux, instead of the
correct ones from a custom header directory, move system include
directories to the back of the header path list. Also to match what
CMake seems to be doing for the C compiler command-lines it generates.
CMake seems to use `-I`, while for these invocations we stick with
`-isystem` just in case.
This area remains fragile and likely not the final issue.
Fixing (seen in GHA/linux H3 c-ares):
```
Error while processing bld/tests/libtest/lib1521.c.
/usr/include/openssl/macros.h:147:4: error: "OPENSSL_API_COMPAT expresses an impossible API compatibility level" [clang-diagnostic-error]
Found compiler error(s).
147 | # error "OPENSSL_API_COMPAT expresses an impossible API compatibility level"
| ^
FAILED: [code=1] tests/libtest/CMakeFiles/libtests-clang-tidy
```
Ref: https://github.com/curl/curl/actions/runs/22468472670/job/65079885471?pr=20751
Bug: https://github.com/curl/curl/pull/20751#issuecomment-3970180687
Cherry-picked from #20751Closes#20759
Fixing:
```
CMake Error at /path/to/CURL/CURLConfig.cmake:190 (get_target_property):
get_target_property() called with non-existent target "CURL::libssh2".
```
and replacing it with the clearer message:
```
CMake Error at /path/to/CURL/CURLTargets.cmake:61 (set_target_properties):
The link interface of target "CURL::libcurl_static" contains:
CURL::libssh2
but the target was not found. Possible reasons include:
[...]
```
Reported-by: Val S.
Ref: #20729
Follow-up to 16f073ef49#16973Closes#20737
Pass system directories with `-isystem` to avoid clang-tidy parsing
3rd-party and system headers with `HeaderFilterRegex: '.*' enabled.
Also:
- drop rule exception no longer necessary.
- sync normal vs. system header path order with compiler invocation.
- tidy up `set()` syntax.
- clear a temporary variable.
Bug: https://github.com/curl/curl/pull/20670#issuecomment-3940840176
Follow-up to e088e10454#17705
Cherry-picked from: #20720Closes#20724
- 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
To avoid breaking 3rd-party code reusing these symbols as C++ methods,
e.g. in CMake sources:
```
cmake/src/v4.0.0-b30653ae0c.clean/Source/cmCurl.cxx:119:24: error: expected unqualified-id
119 | ::CURLcode res = ::curl_easy_setopt(curl, CURLOPT_CAINFO, cafile.c_str());
| ^
```
Also expand comment to highlight the case.
Reported-by: Kai Pastor
Bug: daa6b27b4d (r177869049)
Reported-by: Marcel Raad
Bug: https://curl.se/mail/lib-2026-02/0020.htmlFixes#20682
Follow-up to daa6b27b4d#20597Closes#20686
By passing to clang-tidy the C compiler with `--target` and sysroot
options, if any.
Fixing (GHA/windows, linux-mingw, CM clang-tidy):
```
lib/curl_setup.h:841:10: error: 'io.h' file not found [clang-diagnostic-error]
841 | #include <io.h>
| ^~~~~~
Found compiler error(s).
FAILED: [code=1] tests/server/CMakeFiles/servers-clang-tidy bld/tests/server/CMakeFiles/servers-clang-tidy
cd tests/server && /usr/bin/clang-tidy --config-file=.clang-tidy.yml
--warnings-as-errors=* --checks=-clang-diagnostic-unused-function first.c getpart.c util.c dnsd.c [...]
-- <-D-options> <-I-options> <cflags>
```
For reference, this is CMake's built-in clang-tidy invocation:
```
/usr/local/bin/cmake -E __run_co_compile --tidy="/usr/bin/clang-tidy;--config-file=.clang-tidy.yml;
--warnings-as-errors=*;--extra-arg-before=--driver-mode=gcc" --source=lib/curl_fopen.c
-- /usr/bin/clang --target=x86_64-w64-mingw32 <-D-options> <-I-options> <cflags>
```
Also:
- bump cmakelint `--max-statements`. Needs 59 after this patch.
- use undocumented CMake variables:
- `CMAKE_C_COMPILE_OPTIONS_TARGET` for `--target=`
- `CMAKE_C_COMPILE_OPTIONS_SYSROOT` for `--sysroot=`
Cherry-picked from #20631Closes#20640
Seen with mbedTLS 4.0.0. mbedTLS 4.0.0 renamed `mbedcrypto` lib to
`tfpsacrypto`, while also keeping a copy under the old name to aid
transition. However, this compatibility logic is broken for MSVC static
builds, and the old name missing.
Work around by looking for the new name in the raw detection codepath.
Note that using `pkg-config`-based detection also works as a workaround.
Reported-by: tawmoto on github
Fixes#20616
Ref: https://github.com/Mbed-TLS/mbedtls/blob/v4.0.0/library/CMakeLists.txt#L275-L282
Ref: https://github.com/Mbed-TLS/mbedtls/issues/10605Closes#20617
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
To fix potential `-Wdisabled-macro-expansion` warnings when using these
macros within other macros. Fixing for example:
```
lib/doh.c:328:3: error: disabled expansion of recursive macro [clang-diagnostic-disabled-macro-expansion,-warnings-as-errors]
328 | ERROR_CHECK_SETOPT(CURLOPT_URL, url);
| ^
lib/doh.c:271:14: note: expanded from macro 'ERROR_CHECK_SETOPT'
271 | result = curl_easy_setopt((CURL *)doh, x, y); \
| ^
include/curl/curl.h:3332:44: note: expanded from macro 'curl_easy_setopt'
3332 | #define curl_easy_setopt(handle,opt,param) curl_easy_setopt(handle,opt,param)
| ^
[...]
```
Also update comments on why curl continues to disable
`-Wdisabled-macro-expansion` and `-Wused-but-marked-unused` warnings.
Follow-up to 92f215fea1#18477Closes#20597
Upgrade a GHA/windows job to VS2026 (from VS2022), using a runner image
released a week ago. It also comes with the same Windows SDK as VS2022:
v10.0.26100.0.
The runner image uses Windows 2025 unfortunately, which makes the job
run significantly slower than before this patch:
- configure: 49s -> 1m10s
- build: 3s -> 5s
- install test prereqs: 23s -> 27s
- run tests: 3m18s -> 4m11s
- build examples: 15s -> 25s
It's a shame.
Also:
- cmake: enable picky warnings for VS2026 internal version 19.50.
Build is clean with existing options.
- GHA/windows: make the built-in OpenSSH intall path recognize
the windows-2025-vs2026 image as windows-2025.
- windows-2025-vs2026 is able to load the cached stunnel made on
the windows-2022 runner.
- disk use of the build is almost identical to VS2022.
Before: https://github.com/curl/curl/actions/runs/21955482367/job/63418133880
After: https://github.com/curl/curl/actions/runs/21957589847/job/63426546943
Ref: 71f0157880/images/windows/Windows2025-VS2026-Readme.md
Ref: #20575Closes#20577
Drop detecting it at configure time, along with the interim macro
`HAVE_MSG_NOSIGNAL`. There is no longer a reason for this workaround,
and allows to save the work at configure time and simplify.
Also say in a comment that `sys/socket.h` is defining this macro.
Follow-up to 77b3bc239dCloses#20559
- 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
Stop detecting this function and drop the local fallback.
Let us know if this update is causing an issue.
Notes:
- on Windows `_strdup()` is required instead.
- `strdup()/_strdup()` were required before this patch to build one of
the examples: `block_ip`.
- `strdup()/_strdup()` were required in 8.18.0 and earlier to build
tests.
Closes#20505
Via options:
- `BROTLI_USE_STATIC_LIBS`
- `CARES_USE_STATIC_LIBS`
- `LIBSSH_USE_STATIC_LIBS`
- `LIBSSH2_USE_STATIC_LIBS`
- `MBEDTLS_USE_STATIC_LIBS`
- `NGHTTP2_USE_STATIC_LIBS`
- `NGHTTP3_USE_STATIC_LIBS`
- `NGTCP2_USE_STATIC_LIBS`
- `ZSTD_USE_STATIC_LIBS`
When enabled, make a "best effort" finding static libs first and set
the "build static" macro (on Windows) as required by the dependency.
When doing `pkg-config`-based detections, make curl select the static
configuration, which shall set the "build static" macro also.
These options resemble CMake's `OPENSSL_USE_STATIC_LIBS` and
`ZLIB_USE_STATIC_LIBS` (the latter does not support `pkg-config` as of
CMake v4.2.2).
Shared/static library selection based on loose filename conventions is
fragile and prone to break if the non-static-suffixed library is found
and happens to be a shared library, or, if the linker decides to pick up
a shared copy (e.g. `.a.dll`) that shadows the static one. It may help
to provide either static or shared, but not both, on the disk, and match
that with this setting.
Experimental.
Ref: #20013Closes#20015
While working #16973, the binutils ld lib order workaround logic
regressed so that it modified the wrong target, writing into the system
`ZLIB::ZLIB` and `OpenSSL::Crypto` ones a `INTERFACE_LINK_LIBRARIES`
property, instead of creating CURL-namespaced targets. Oddly enough,
this also fixed the binutils ld lib ordering issue. It seems this
property makes CMake insert each referenced library in two more
positions (not at the very end though), which allows ld to resolve all
symbols in the cases tested in CI.
Fix by creating the indented namespaced targets, and also creating
these in `curl-config.cmake` to be available when consuming libcurl.
Note that the logic continues doing `get_target_property()` on the two
system targets above. If these targets are defined manually and miss
the `LOCATION` propery, or are defined as aliases, this command may
fail. curl expects these targets be created by CMake's `FindZLIB` and
`FindOpenSSL` built-in Find modules (or ones compatible). Ref: #20419
The binutils ld issue is reproduced by these CI jobs:
- Linux gcc glibc (amd64, arm64)
- Windows gcc zlib-classic (x64)
Currently using this curl-for-win revision:
7d12669daf
Examples:
https://github.com/curl/curl/actions/runs/21332437230/job/61399234023?pr=20427https://github.com/curl/curl/actions/runs/21332437230/job/61399234033?pr=20427
Comparison of lib orders, as passed by CMake to the linker:
without workaround (possibly breaking binutils `ld`):
```diff
-framework [...]
libssl.dylib
libcrypto.dylib
libz.tbd
-lssh2 -lidn2
libldap.tbd
liblber.tbd
-lbrotlidec -lbrotlicommon -lzstd -lnghttp2 -lpsl -lrtmp
-lz
-lssl
-lcrypto
```
before this patch:
```diff
-framework [...]
libssl.dylib
libcrypto.dylib
libz.tbd
+libcrypto.dylib <== inserted via `INTERFACE_LINK_LIBRARIES`
+libz.tbd <== inserted via `INTERFACE_LINK_LIBRARIES`
-lssh2 -lidn2
libldap.tbd
liblber.tbd
+libcrypto.dylib <== inserted via `INTERFACE_LINK_LIBRARIES`
+ibz.tbd <== inserted via `INTERFACE_LINK_LIBRARIES`
-lbrotlidec -lbrotlicommon -lzstd -lnghttp2 -lpsl -lrtmp
-lz
-lssl
-lcrypto
```
after this patch:
```diff
-framework [...]
libssl.dylib
libcrypto.dylib
libz.tbd
-lssh2 -lidn2
libldap.tbd
liblber.tbd
-lbrotlidec -lbrotlicommon -lzstd -lnghttp2 -lpsl -lrtmp
-lz
-lssl
-lcrypto
+libcrypto.dylib <== inserted via `CURL::OpenSSL_Crypto`
+libz.tbd <== inserted via `CURL::ZLIB`
```
Bug: https://github.com/curl/curl/pull/20382#discussion_r2716660108
Reverts: 615c43eae8
Follow-up to 16f073ef49#16973Closes#20427
The CMake config can be consumed by project which enable only language
`CXX`. `CMAKE_C_COMPILER_ID` isn't defined in this case, and the target
definition would be missing. But the check for compiler id isn't really
needed: The target is namespaced and valid, regardless of actual
compiler.
Noticed in https://github.com/microsoft/vcpkg/issues/49518, building cpr.
Follow-up to 16f073ef49#16973Closes#20382
