Public curl headers are best not to define 3rd-party or system macros.
Introduce `CURL_HAS_DECLSPEC_ATTRIBUTE` to cover this system macro and
use it.
Detected by test1167 after dropping the indentation:
```
test 1167...[Verify curl prefix of public symbols in header files]
/usr/bin/perl -I. -I. returned 1, when expecting 0
1167: exit FAILED
== Contents of files in the log/10/ dir after test 1167
=== Start of file server.cmd
Testnum 1167
=== End of file server.cmd
=== Start of file stdout1167
Bad symbols in public header files:
__has_declspec_attribute(x)
=== End of file stdout1167
```
Ref: https://github.com/curl/curl/actions/runs/13533200900/job/37819784405?pr=16490#step:42:2087
Ref: https://clang.llvm.org/docs/LanguageExtensions.html#has-declspec-attribute
Follow-up to 50482b8c0a#3616
Ref: #16496 (fixing test1167)
Closes#16491
`./configure` mingw32ce builds enable C99 mode automatically, that
triggers compiler warnings in gcc 4.4.0. We initially worked it around
in CI by suppressing the detection of C99 with `ac_cv_prog_cc_c99=no`.
Replace it with automatically silencing the bogus warnings in C99 mode,
for all build systems:
```
lib/ftp.c: In function 'Curl_GetFTPResponse':
lib/ftp.c:726: error: format '%zd' expects type 'signed size_t', but argument 4 has type 'ssize_t'
lib/ws.c: In function 'ws_dec_pass_payload':
lib/ws.c:304: error: format '%zd' expects type 'signed size_t', but argument 3 has type 'ssize_t'
lib/ws.c: In function 'ws_enc_write_head':
lib/ws.c:581: error: format '%zd' expects type 'signed size_t', but argument 3 has type 'long int'
lib/vtls/schannel.c: In function 'schannel_connect_step1':
lib/vtls/schannel.c:1122: error: format '%zd' expects type 'signed size_t', but argument 3 has type 'ssize_t'
lib/vtls/schannel.c: In function 'schannel_connect_step2':
lib/vtls/schannel.c:1311: error: format '%zd' expects type 'signed size_t', but argument 3 has type 'ssize_t'
lib/vtls/schannel.c: In function 'schannel_send':
lib/vtls/schannel.c:1793: error: format '%zd' expects type 'signed size_t', but argument 3 has type 'ssize_t'
lib/vtls/schannel.c:1810: error: format '%zd' expects type 'signed size_t', but argument 3 has type 'ssize_t'
lib/vtls/schannel.c: In function 'schannel_shutdown':
lib/vtls/schannel.c:2286: error: format '%zd' expects type 'signed size_t', but argument 4 has type 'ssize_t'
lib/vtls/vtls.c: In function 'ssl_cf_recv':
lib/vtls/vtls.c:1422: error: format '%zd' expects type 'signed size_t', but argument 5 has type 'ssize_t'
```
Ref: https://github.com/curl/curl/actions/runs/13533841306/job/37821720902?pr=16492#step:9:20
Also: simplify Windows CE job configuration in GHA/windows.
Follow-up to 2a292c3984#15975Closes#16492
We decided not to show warnings for this issue.
Also this:
```
CMake Warning at CMakeLists.txt:783 (message):
OpenSSL does not support TLS 1.3.
```
as seen in #16483 with CMake 3.12.4, `OPENSSL_VERSION` is empty.
Perhaps detection isn't reliable? I haven't seen this so far with
mainline OpenSSL. An `if(OPENSSL_VERSION AND ...)` can fix it, if we
opt for this warning in the future.
Follow-up to #16122
This reverts commit 34c1c653fc#16120Closes#16485
- Show verbose message if the CA native import option is set but
the wolfSSL build does not support it.
wolfSSL has to be built with WOLFSSL_SYS_CA_CERTS to import native
CA certificates and that may not be common.
Closes https://github.com/curl/curl/pull/16417
To help applications do the right thing easier, change some enum values
into defines with L suffixes so that they get the corect type (long)
easier when used with curl_easy_setopt(). This also fixes a few of our
own libtests.
To reduce the risk that this change breaks the compile for any existing
users, the previously provided enums are still provided, but the values
to use are not defined by the enums.
This change "magically" fixes a few RTSP test failures we have had on
64-bit platforms because those options were not see using longs
properly.
Closes#16482
Sync cutoff version for `-ftree-vrp` with autotools, which enables it
for gcc 4.3+ (cmake builds enabled it for 5.0+, before this patch).
Cherry-picked from #16476Closes#16478
To save configuration time.
After this patch, for mingw-w64 and MSVC curl's CMake builds pre-fill
almost all type sizes without auto-detection. In most cases this leaves
3 type size auto-detections. Those depend on 64/32-bitness, and `time_t`
also depends on CRT and custom options. Old mingw-w64 versions require
some extra detections. We recommend v3.0 or newer to avoid them.
For Windows CE, this patch pre-fills all type sizes.
If this is causing any issue, please report it and disable pre-filling
with `-D_CURL_PREFILL=OFF` in the meantime.
Cherry-picked from #16394Closes#16464
This PR updates the CMake build/install docs in `docs/INSTALL-CMAKE.md`,
in particular focusing on the use of libcurl from CMake using
`find_package` as well as the newly added features/protocols support via
using `COMPONENTS` or `OPTIONAL_COMPONENTS` with `find_package`.
See #15854 for initial discussion and the corresponding PR #15858 that
was merged.
Some additional best-practices notes are added, for example:
* Encouraging building out-of-source
* Using `--config` with `cmake --build` for multi-config CMake
generators, not `CMAKE_BUILD_TYPE`
We also add a CURL CMake-specific tip on using `CMAKE_INSTALL_PREFIX`
during configure time to set the install prefix, not using `--prefix`
when running `cmake --install` so `curl-config` output is consistent.
Closes#16329
This allows you to use the `certs` and `num_certs` writeout variables in
the curl tool, and getting information about the server certificates
using CURLINFO_CERTINFO.
Closes#16459
Drop the `getpart` test tool from standard builds. This tool was not
used by tests.
Also:
- make it easier to build it standalone for testing `getpart.c` on
the command-line.
- reduce local var scopes in source.
Closes#16460
- appveyor: restore VS2008 job, after fixing its issues.
Enable OpenSSL in it. It takes 1 minute.
Follow-up to 9b0467b169#16453
Follow-up to edfa537100#16456
- appveyor: make a copy of OpenSSL DLLs to have them picked up as an
artifact (disabled by default) to aid local tests.
- appveyor: dump CMake configuration logs on failure.
- appveyor: tidy up job parameter defaults.
- GHA/windows: add pre-fill check option for dl-mingw jobs.
- GHA/windows: fix pre-fill check option for MSYS jobs by installing
`diffutils`.
Follow-up to e7adf3e837#15841
- GHA/windows: de-duplicate to `PATH` commands for Cygwin.
- GHA/windows: drop `$SYSTEMROOT/System32` from `PATH` for Cygwin
configure. It's not needed.
Follow-up to 36fd2dd6ee#13599
- list `.pdb` files in curl version step for MSVC.
Ref: #16439
Cherry-picked from #16394Closes#16458
Static CRT crashes MSVCR* MSVC builds (in VS2008, VS2010, VS2012,
VS2013) according to CI and local tests. The reproducible crash happens
in `curl_mfprintf() -> fputc(s, stderr)` when trying to display the
warning message in `curl -V`. `stderr` is non-NULL and resolves to `2`.
This reproducer needs a debug-enabled build, but it's unrelated to debug
features or curl's memory tracker. It happens regardless of unity build,
CPU architecture or `DllMain()` use. Example from VS2013:
```
+ _bld/src/Debug/curl.exe --disable --version
./appveyor.sh: line 124: 203 Segmentation fault "${curl}" --disable --version
```
Ref: https://ci.appveyor.com/project/curlorg/curl/builds/51570451/job/ojpdqrsm1hmpmq6a#L210
Another crash happened in an UCRT build (VS2017) with a couple of
`printf()`s added to curl's `main()` function:
```
Microsoft Visual C++ Runtime Library
Debug Assertion Failed!
Program: C:/projects/curl/bld/src/Debug/curl.exe
File: minkernel/crts/ucrt/src/appcrt/heap/debug_heap.cpp
Line: 996
Expression: _act_first_block == header
```
(it hangs the job in CI due to the GUI popup)
Ref: https://github.com/curl/curl/pull/16394#issuecomment-2677181716
To avoid actual and potential issues, this patch issues a warning on
the shared-libcurl + static-CRT combination and falls back to the
default, shared CRT. IOW a static CRT build now requires a static curl
exe when using the `CURL_STATIC_CRT=ON` option.
Follow-up to 4fc6ebe18a#1621
Cherry-picked from #16394 (with more details there)
Closes#16456
