- Restore some necessary options for builds without HTTP and MQTT.
The logic to turn off a segment of options in builds without HTTP and
MQTT was too expansive. Those builds (such as FTP-only builds) could not
use options such as CURLOPT_URL or CURLOPT_USERNAME etc.
Prior to this change 30da1f59 (precedes 8.11.0) refactored the options
processing and caused this issue.
Reported-by: Yoshimasa Ohno
Fixes https://github.com/curl/curl/issues/15634
Closes https://github.com/curl/curl/pull/15640
This makes `runtests.pl` run the final executables directly.
Before this patch it called the autotools/libtool wrapper tool, which
then called the final executables.
This solution was already used for `curl.exe`.
Applies to tests run in the `mingw, AM x86_64 c-ares U` job, which still
shows unexplained flakiness.
Also makes tests finish 45 seconds faster.
Ref: #14854
Follow-up to 1a2d38c47c#15437Closes#15662
The MSVC UWP job in CI did not actually enable UWP. Fix this and
the fallouts discovered after enabling it.
- GHA/windows: make sure to enable UWP in MSVC vcpkg UWP job.
Use the CMake options and C flags already used for mingw-w64, but use
`WINAPI_FAMILY_PC_APP` instead of the deprecated `WINAPI_FAMILY_APP`.
(The former is not supported by mingw-w64, so leave it there as-is.)
Follow-up to cb22cfca69#14077
- GHA/windows: by default the MSVC UWP job became 2x-3x slower than
others after actually enabling UWP. Most of it is caused by
CMake/MSBuild automatically building full APPX containers for each
`.exe` target. This includes 21 CMake feature detections. Each
detection app is built into a 15MB APPX project, with code signing,
logos, etc. Example:
https://github.com/curl/curl/actions/runs/12056968170/job/33620610958
Disable this overhead for curl build targets via custom
`CMAKE_VS_GLOBALS` options. I've found no way to apply them to feature
detection targets, so those remain slow.
- cmake: automatically enable Unicode for UWP builds. It's required.
Also stop enabling it manually in the existing CI job.
- tests: fix `getpid()` use for Windows UWP:
```
tests\server\util.c(281,21): warning C4013: 'getpid' undefined; assuming extern returning int
```
Ref: https://github.com/curl/curl/actions/runs/12061215311/job/33632904249#step:11:38
- src/tool_doswin: disable `GetLoadedModulePaths()` for UWP.
mingw-w64 UWP was okay with this, but MS SDK headers are not.
This makes `--dump-module-paths` return empty for UWP builds.
```
src\tool_doswin.c(620,3): error C2065: 'MODULEENTRY32': undeclared identifier
src\tool_doswin.c(626,11): warning C4013: 'CreateToolhelp32Snapshot' undefined; assuming extern returning int
src\tool_doswin.c(626,36): error C2065: 'TH32CS_SNAPMODULE': undeclared identifier
src\tool_doswin.c(632,7): warning C4013: 'Module32First' undefined; assuming extern returning int
```
Ref: https://github.com/curl/curl/actions/runs/12055081933/job/33614629930#step:9:35
- examples: fix `websocket.c` to include `winsock2.h` before `windows.h`
to make it build with MSVC UWP:
```
include\curl\curl.h(143,16): error C2061: syntax error: identifier 'curl_socket_t'
include\curl\curl.h(143,16): error C2059: syntax error: ';'
include\curl\curl.h(417,52): error C2146: syntax error: missing ')' before identifier 'curlfd'
include\curl\curl.h(417,38): error C2081: 'curl_socket_t': name in formal parameter list illegal
```
Ref: https://github.com/curl/curl/actions/runs/12055317910/job/33615644427#step:14:126
- GHA/windows: silence linker warning with MSVC UWP builds:
```
LINK : warning LNK4075: ignoring '/INCREMENTAL' due to '/OPT:ICF' specification
```
Ref: https://github.com/curl/curl/actions/runs/12055696808/job/33616629610#step:11:38
- GHA/windows: set `/INCREMENTAL:NO` for all MSVC jobs to improve
performance a little.
- cmake: show `UWP` platform flag.
Ref: #15652Closes#15657
The ECH feature cannot be built without HTTPS RR.
ECH automatically implied HTTPS RR in `./configure` but not in CMake,
winbuild, documentation.
Also update documentation and CI configs.
Follow-up to a362962b72#11922Closes#15648
Merge cmake and autotools build steps for cygwin, msys2 and
cross-linux jobs.
Advantages:
- makes it easier to keep the two build tracks in sync.
- uses the same steps across jobs.
- avoids scrolling through greyed out steps.
- syncs steps with other workflows already merged like this.
- less code.
Also:
- stop ignoring WebSockets tests results for msys2/mingw-w64 cmake jobs,
except for 2301 2302 that were also ignored for autotools. Syncing the
two build methods.
- drop 'cmake' from step names where cmake was the only build tool.
This was redundant as "CM" already indicates it in the job name.
Closes#15643
- GHA/windows: switch mingw-w64 UWP CI job to use UCRT.
`msvcr120_app` was missing `getch()` for example.
Follow-up to f988842d85#15637
This job tests compiling for UWP correctly, but the the resulting
`curl.exe` still doesn't look like a correct UWP app, now exiting
on startup with: `curl: error initializing curl library`.
- tool_getpass: restore `getch()` for UWP builds.
Follow-up to f988842d85#15637
- schannel: silence `-Werror=null-dereference` warning in mingw-w64 UWP:
```
lib/vtls/schannel_verify.c: In function 'Curl_verify_host':
lib/vtls/schannel_verify.c:558:33: error: null pointer dereference [-Werror=null-dereference]
558 | for(i = 0; i < alt_name_info->cAltEntry; ++i) {
| ~~~~~~~~~~~~~^~~~~~~~~~~
lib/vtls/schannel_verify.c:559:50: error: null pointer dereference [-Werror=null-dereference]
559 | PCERT_ALT_NAME_ENTRY entry = &alt_name_info->rgAltEntry[i];
| ~~~~~~~~~~~~~^~~~~~~~~~~~
```
Ref: https://github.com/curl/curl/actions/runs/12022656065/job/33515255397?pr=15638#step:19:27
Follow-up to 9640a8ef6f#15421
- GHA/windows: fix `find` command in MSVC job step.
Follow-up to 5f9411f953#15380
- GHA/windows: drop unnecessary `windowsappcompat` lib from mingw-w64
UWP job. Also drop related MSYS2 package.
- GHA/windows: cmake 3.31.0 still invokes `windres` with wrong options
with mingw-w64 UPW. Update curl version in comment accordingly.
- GHA/windows: tidy up mingw-w64 UWP spec logic, limit it to gcc.
- GHA/windows: update comments on `curl.exe` UWP startup errors.
Closes#15638
The CRT call `getch()` isn't supported on Windows UWP. This function is
used to implement `getpass_r()` for reading a password from the console,
for platforms not supporting it natively. This patch makes this function
a dummy, so password entry from the command-line is no longer supported
for UWP apps. Though it probably did not work before this patch, due to:
CRT headers do declare `getch()`, but it's missing from the CRT DLL.
MSDN documents it as unsupported for UWP:
https://learn.microsoft.com/cpp/c-runtime-library/reference/getchhttps://learn.microsoft.com/cpp/c-runtime-library/reference/getch-getwch
Same is true for the non-deprecated `_getch()` function.
After mingw-w64 synced its implib with `msvcr120_app.dll`, the CI job
`mingw, CM x86_64 schannel R uwp` broke with:
```
[16/16] Linking C executable src\curl.exe
FAILED: src/curl.exe
[...]
D:/a/_temp/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/14.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
src/CMakeFiles/curl.dir/Unity/unity_0_c.c.obj:unity_0_c.c:(.text+0x4d05): undefined reference to `getch'
```
Ref: https://github.com/curl/curl/actions/runs/11873795410/job/33089008727?pr=15597#step:19:25
Also:
- GHA/windows: bump `msys2/setup-msys2` action to
https://github.com/msys2/setup-msys2/commit/c52d1fa
This triggered the build failure above.
Closes#15597
Ref: d408f51e5a/tree/mingw-w64-crt/def-include/crt-aliases.def.inCloses#15637
Issue is reproducible for me if I have made request with multi handle,
then I make request that will take very long and then I make request
that should be fast again, however what happens it is that it seems
to think that timeout was not changed and it makes it not call initial
`CURLMOPT_TIMERFUNCTION`.
Closes#15627
Instead of the Git repo tag which requires downloading the tip of
a dependency repository at the time of bumping version:
https://github.com/Mbed-TLS/mbedtls-framework
The official source tarball ships with this dependency, making
the CI builds reproducible.
Also: fold long download commands for other dependencies.
Closes#15632
Build in parallel first, then install with `-j1`. This makes the build
part 3x quicker, while avoiding parallellism issues at the install
phase.
```
before after after
1da198d this
aws-lc: 1m55s ~40s
libressl: 1m16s ~1m20s
openssl-tsan: 5m47s 3m43s 1m48s (clang)
openssl: 6m38s 4m49s 2m13s (quic)
quictls-no-deprecated: 2m28s 1m51s
quictls: ~6m08s 4m16s 1m55s
wolfssl-all: 1m36s 52s
wolfssl-master: 1m34s 53s
wolfssl-opensslextra: 50s 32s
```
Follow-up to 1da198d18e#15622Closes#15630
Also:
- for LibreSSL download the official source tarball instead of
using the tagged Git repo and running the build script which
merged the OpenBSD libressl repo into it. The latter method
was also broken at the time of this commit.
Build times:
```
before after
aws-lc: 1m55s ~40s
libressl: 1m16s ~1m20s
openssl-tsan: 5m47s 3m43s
openssl: 6m38s 4m49s
quictls-no-deprecated: 2m28s 1m51s
quictls: ~6m08s 4m16s
wolfssl-all: 1m36s 52s
wolfssl-master: 1m34s 53s
wolfssl-opensslextra: 50s 32s
```
LibreSSL build options are unchanged, but by using the tarball now
instead of two repos and a generator script, it also should be faster,
and more stable.
Closes#15622
It was missing while detecting `wolfSSL_DES_ecb_encrypt`,
`wolfSSL_BIO_new` and `wolfSSL_BIO_set_shutdown`.
We have not seen it causing issues in stable wolfSSL releases as of
v5.7.4, until a recent commit in wolfSSL master, which broke detections:
```
curl/CMakeFiles/CMakeScratch//CheckSymbolExists.c:8:19: error: ‘wolfSSL_BIO_new’ undeclared (first use in this function); did you mean ‘wolfSSL_CTX_new’?
curl/CMakeFiles/CMakeScratch//CheckSymbolExists.c:8:19: error: ‘wolfSSL_BIO_set_shutdown’ undeclared (first use in this function); did you mean ‘wolfSSL_set_shutdown’?
```
This in turn disabled `HTTPS-proxy` and failed related pytests:
https://github.com/curl/curl/actions/runs/11953800545/job/33324250039?pr=15620
wolfSSL source diff causing the regression:
be70bea687..c06f65a8ac
The wolfSSL build says:
```
Note: Make sure your application includes "wolfssl/options.h" before any other wolfSSL headers.
You can define "WOLFSSL_USE_OPTIONS_H" in your application to include this automatically.
```
This patch makes sure to follow this rule across the curl codebase.
Also:
- include `wolfssl/options.h` first in `lib/vtls/wolfssl.c`.
It was preceded by `wolfssl/version.h`, which did not cause issues.
Background for the pre-existing include order:
Ref: deb9462ff2#3903
Ref: https://curl.se/mail/lib-2015-04/0069.html
Bug: https://github.com/curl/curl/pull/15620#issuecomment-2491872463
Follow-up to d68a121266#14064Closes#15623
Sync with autotools and filter out most linker flags inherited via
`CMAKE_SHARED_LINKER_FLAGS` (that includes `LDFLAGS` env) before
echoing them in `libcurl.pc` `Libs.private` and `curl-config`
`--static-libs`.
Keep inheriting `-l`, `-L`, `-F`, `--library-path=`, `-framework`
options.
Follow-up to e244d50064#15550
Follow-up to 9f56bb608e#14681
Follow-up to 8ed66f98a9Closes#15617
- Instead of saying "do not use", explain that the function was
deprecated for performance reasons.
Some users may have a legitimate use of this function even though we
deprecated it. Since there are no plans to remove it from the API get
rid of the "do not use" warning.
Bug: https://curl.se/mail/lib-2024-11/0029.html
Reported-by: Jacob Champion
Closes https://github.com/curl/curl/pull/15576
curl offers a `--user-agent` option for modifying the `User-Agent`
header supplied in its requests.
The man page section for this option explains how to use the
`--user-agent` option, but does not explain which `User-Agent` curl uses
by default.
By default, curl uses curl/VERSION, such as `User-Agent: curl/8.11.0`.
Note that this appears to be different from the libcurl default (no
User-Agent header).
This commit documents the default `User-Agent` in the man page section
for the `--user-agent` option, as well as on the "Art of Scripting"
page.
The `%VERSION` placeholder will be used to insert the current version
as described in the man page generator docs.
Closes#15608
- make sure that a match that returns a username also returns a
password, that should be blank if no password is found
- fix handling of multiple logins for same host where the password/login
order might be reversed.
- reject credentials provided in the .netrc if they contain ASCII control
codes - if the used protocol does not support such (like HTTP and WS do)
Reported-by: Harry Sintonen
Add test 478, 479 and 480 to verify. Updated unit 1304.
Closes#15586
- fix socket/sockindex confusion on writes:
The callstack used to end with `Curl_write_plain()` accepting a socket
till 7.87.0. This call got swapped for `Curl_conn_send()`, expecting
a sockindex. `socket_write()` was updated accordingly. Its callers
missed it and continued operating on sockets: `do_sec_send()`,
`sec_write()`, passing it down the stack and `Curl_conn_send()`
resolving it as if it were a sockindex.
It affected FTP Kerberos authentication.
Discovered through MSVC warnings:
```
curl\lib\krb5.c(652,28): warning C4244: 'function': conversion from 'curl_socket_t' to 'int', possible loss of data
curl\lib\krb5.c(654,28): warning C4244: 'function': conversion from 'curl_socket_t' to 'int', possible loss of data
curl\lib\krb5.c(656,26): warning C4244: 'function': conversion from 'curl_socket_t' to 'int', possible loss of data
curl\lib\krb5.c(657,26): warning C4244: 'function': conversion from 'curl_socket_t' to 'int', possible loss of data
curl\lib\krb5.c(665,24): warning C4244: 'function': conversion from 'curl_socket_t' to 'int', possible loss of data
curl\lib\krb5.c(666,24): warning C4244: 'function': conversion from 'curl_socket_t' to 'int', possible loss of data
```
Ref: https://github.com/curl/curl/actions/runs/11846599621/job/33014592805#step:9:32
Follow-up to 5651a36d1a#10280
Bug: https://github.com/curl/curl/pull/15549#issuecomment-2474154067Fixes#15582
- fix uninitialized buffer:
```
curl\lib\krb5.c(288,1): warning C4701: potentially uninitialized local variable '_gssresp' used
```
Ref: https://github.com/curl/curl/actions/runs/11848626645/job/33020501026?pr=15585#step:9:31
- silence unreachable code compiler warning:
```
curl\lib\krb5.c(370,1): warning C4702: unreachable code
```
Ref: https://github.com/curl/curl/actions/runs/11848626645/job/33020501026?pr=15585#step:9:30Closes#15585
Fixing issue #15580 by renaming struct var to tool_var to avoid conflict
with the same structure name defined in AIX system headers.
Fixes#15580Closes#15581
This feature was recently dropped because of a bad side-effect of
silencing unused cmake command-line option warnings.
Fix this issue by retrieving variable values using `get_property()`,
instead of accessing the variables directly. It allows restoring
this feature without the bad side-effect.
Also limit the logic to CI runs.
Follow-up to 96edb5f611#15501Closes#15563
The idea of linking dependencies found to `libcurl.pc` turns out not
to work in practice in some cases.
Specifically: gss, ldap, mbedtls, libmsh3, rustls
A `.pc` may not work or be missing for a couple of reasons:
- not all build methods generate it: mbedTLS, Rustls
- generated file is broken: msh3
Ref: https://github.com/nibanks/msh3/pull/225
- installed package flavour isn't shipping with one:
FreeBSD GSS, OmniOS LDAP, macOS LDAP
The effect of such issues shall be subtle in theory, because
`libcurl.pc` normally lists these dependencies in the `Requires.private`
section meant for static linking. But, e.g. `pkg-config --exists`
requires these to be present, and builds sometimes use this check
regardless of build type. This bug is not present in `pkgconf`; it only
checks for them when `--static` is also passed.
Fix these by adding affected `.pc` references to `libcurl.pc` only when
we detected the dependency via `pkg-config`.
There are a few side-effects of this solution:
- references are never added for dependencies where curl doesn't
implement `pkg-config` detection. These are:
- autotools: ldap, mbedtls, msh3
- cmake: ldap (pending #15273)
- generated `libcurl.pc` depends on the build-time environment.
- generated `libcurl.pc` depends on curl build tool (cmake, autotools).
- generated `libcurl.pc` depends on curl build implementation details.
Make an exception for GNU GSS, where I blindly guess that `gss.pc` is
always available, as no issues were reported.
Other, not mentioned, dependencies continue to be added regardless
of the detection method.
Reported-by: Harmen Stoppels, Thomas, Daniel Engberg, Andy Fiddaman
Fixes#15469Fixes#15507Fixes#15535
Fixes https://github.com/curl/curl/pull/15163#issuecomment-2473358444Closes#15573
- stop passing explicit libpaths via `CMAKE_SHARED_LINKER_FLAGS` and
`CMAKE_EXE_LINKER_FLAGS`. `link_directories()` is doing that already.
- use `curl_required_libpaths()` to pass libpaths to the feature test.
Reported-by: Daniel Engberg
Fixes#15536
Also fixes GSS feature detection with non-gcc/clang compilers,
such as MSVC.
- add libpaths to `CURL_LIBPATHS`.
- move `GSS_CFLAGS`, `GSS_LDFLAGS` stringifications to FindGSS.
To match the `CFLAGS` format returned by the rest of Find modules.
- reorder calls to match other dependencies.
- don't extend system `LDFLAGS` when FindGSS did not return any.
- ignore `LDFLAGS` when detecting GSS via `pkg-config`. `LDFLAGS` holds
a copy of libpaths and libs in this case. Ignore those to avoid these
duplicates making into `libcurl.pc` and `curl-config`. Also syncing
behavior with other Find modules which also ignore raw `LDFLAGS`.
- ignore raw `LDFLAGS` coming from `krb5-config --libs`. FindGSS
no longer returns dependency-specific `LDFLAGS` after this. Syncing
behavior with other Find modules.
- reduce scope of checker state push/pop/set.
Closes#15545
krb5 defines `strtok_r` for Windows unconditionally in its public
header:
dc5554394e/src/include/win-mac.h (L214-L215)
resulting in this warning:
```
lib\strtok.h(31,9): warning C4005: 'strtok_r': macro redefinition
C:\vcpkg\installed\x64-windows\include\win-mac.h(215,9):
see previous definition of 'strtok_r'
```
The krb5 macro collides with curl's internal definition, in case
the `strtok_r` function is undetected and falling back to a local
replacement.
Reported-by: Tal Regev
Bug: https://github.com/curl/curl/pull/15549#issuecomment-2468251761Closes#15564
`libcurl.pc` `Libs.private` (since 8.11.0, and in `Libs` before 7.20.0)
and `curl-config` `--static-libs` (since 7.17.1, and in `Libs` between
7.7.2-7.25.0). This included all flags inherited from the environment,
in addition to those coming from dependency detections.
To avoid spilling all linker flags inherited from the environment to
the libcurl config files, this patch omits them all, except `-L`, `-F`,
`--library-path=` and `-framework` options, which are still passed.
The rationale for the exceptions is that `LIBS` is passed as-is, and
`LDFLAGS`, `LIBS` are the canonical way to pass custom libs options
to a build. `LIBS` may not work without a matching custom libpath.
This brings autotools behaviour closer to cmake, and `curl-config`
closer to `libcurl.pc`.
Follow-up to 9f56bb608e#14681
Follow-up to 4c8adc8fee
Reported-by: Peter Marko
Fixes#15533Closes#15550
An upstream update `impacket` pip package started requiring `blinker`.
An older version is shipping with Ubuntu, causing this on install:
```
Attempting uninstall: blinker
Found existing installation: blinker 1.7.0
ERROR: Cannot uninstall blinker 1.7.0, RECORD file not found. Hint: The package was installed by debian.
```
Fix it by switching to venv and install everything separate from the
system.
The overhead is the same as using `pip --ignore-installed`, which also
installs everything from scratch.
The 3rd option is to uninstall the system `python3-blinker` package, but
it was the slowest.
Closes#15578
