Logic copied earlier from wolfSSL. wolfSSL requires zlib headers for its
public headers. OpenSSL does not, so stop adding zlib headers for it.
Follow-up to 1e3319a167Closes#10878
* Configure changes to detect AWS-LC
* CMakeLists.txt changes to detect AWS-LC
* Compile-time branches needed to support AWS-LC
* Correctly set OSSL_VERSION and report AWS-LC release number
* GitHub Actions script to build with autoconf and cmake against AWS-LC
AWS-LC is a BoringSSL/OpenSSL derivative
For more information see https://github.com/awslabs/aws-lc/Closes#10320
- fix HTTP/3 support detection with OpenSSL/quictls built with ZLIB.
(Requires curl be built with ZLIB option also.)
- fix HTTP/3 support detection with OpenSSL/quictls/LibreSSL and `ld`
linker on Windows.
- fix HTTP/3 support detection with wolfSSL to automatically add
`ws2_32` to the lib list on Windows. For all linkers.
- reposition ZLIB (and other compression) detection _after_ TLS
detection, but before calling HTTP/3-support detection via
`CheckQuicSupportInOpenSSL`.
May be a regression from ebef55a61d
May fix#10832 (Reported-by: Micah Snyder)
This also seems to fix an odd case, where OpenSSL/quictls is correctly
detected, but its header path is not set while compiling, breaking
build at `src/curl_ntlm_core.c`. Reason for this remains undiscovered.
- satisfy "picky" linkers such as `ld` with MinGW, that are highly
sensitive to lib order, by also adding brotli to the beginning of the
lib list.
- satisfy "picky" linkers by adding certain Windows systems libs to
the lib list for OpenSSL/LibreSSL. (Might need additional ones for
other forks, such as `pthread` for BoringSSL.)
Note: It'd make sense to _always_ add `ws2_32`, `crypt32` (except
Windows App targets perhaps?), `bcrypt` (except old-mingw!) on Windows
at this point. They are almost always required, and if some aren't,
they are ignored by the linker with no effect on final binaries.
Closes#10857
When cross-compiling for Haiku, the networking library needs to be
brought in. Without this, an unknown type of "Error" is reported in
lib/curl_setup_once.h.
This is also needed when using CMake natively on Haiku to build libcurl.
Fixes#10296Closes#10792
- add QUIC/ngtcp2 detection in CMake with wolfSSL.
Because wolfSSL uses zlib if available, move compression detection
before TLS detection. (OpenSSL might also need this in the future.)
- wolfSSL 5.5.0 started using C99 types in its `quic.h` header, but it
doesn't #include the necessary C99 header itself, breaking builds
(unless another dependency pulled it by chance.) Add local workaround
for it. For this to work with all build tools, we had to fix our
header detection first. Ref: #10745
Ref: 6ad5f6ecc1Closes#10739
Fix `stdint.h` and `inttypes.h` detection with non-autotools builds on
Windows. (autotools already auto-detected them accurately.)
`lib/config-win32.h` builds (e.g. `Makefile.mk`):
- set `HAVE_STDINT_H` where supported.
- set `HAVE_INTTYPES_H` for MinGW.
CMake:
- auto-detect them on Windows. (They were both force-disabled.)
- delete unused `CURL_PULL_STDINT_H`.
- delete unused `CURL_PULL_INTTYPES_H`.
- stop detecting `HAVE_STDINT_H` twice.
Present since the initial CMake commit: 4c5307b456
curl doesn't use these C99 headers, we need them now to workaround
broken wolfSSL builds. Ref: #10739
Once that clears up, we can delete these detections and macros (unless
we want to keep them for future us.)
Reviewed-by: Daniel Stenberg
Closes#10745
Before this patch, enabling LDAPS required a manual C flag:
c1cfc31cfc/curl-cmake.sh (L105)
Fix this and enable LDAPS automatically when using `wldap32` (and
when not explicitly disabled). This matches autotools and `Makefile.mk`
behavior. Also remove issue from KNOWN_BUGS.
Add workaround for MSVS 2010 warning triggered by LDAPS now enabled
in more CI tests:
`ldap.c(360): warning C4306: 'type cast' : conversion from 'int' to 'void *' of greater size`
Ref: https://ci.appveyor.com/project/curlorg/curl/builds/46408284/job/v8mwl9yfbmoeqwlr#L312
Reported-by: JackBoosY on github
Reviewed-by: Jay Satiro
Reviewed-by: Marcel Raad
Fixes#6284Closes#10674
- Define OPENSSL_SUPPRESS_DEPRECATED.
OpenSSL 3 has deprecated some of the functions libcurl uses such as
those with DES, MD5 and ENGINE prefix. We don't have replacements for
those functions so the warnings were disabled in autotools and cmake
builds, but still showed in other builds.
Closes https://github.com/curl/curl/pull/10543
Check for CryptAcquireContext in windows.h and wincrypt.h only, since
otherwise this check may fail due to third party headers not found.
Closes https://github.com/curl/curl/pull/10353
Stop explicitly defining `SECURITY_WIN32` in CMake builds.
No other build systems define this macro, because it's unconditionally
defined in `lib/curl_sspi.h` already. This is the only curl source using
the `sspi.h` and `security.h` Win32 headers, and no other Win32 headers
need this macro.
Reviewed-by: Jay Satiro
Closes#10341
curl stopped use of CMAKE_USE_ as a prefix for its own build symbols in
2021 and added a check, meant to last 1 year, to fatally error on those
symbols. This commit removes that check.
Closes https://github.com/curl/curl/pull/10314
- they are mostly pointless in all major jurisdictions
- many big corporations and projects already don't use them
- saves us from pointless churn
- git keeps history for us
- the year range is kept in COPYING
checksrc is updated to allow non-year using copyright statements
Closes#10205
Because this is the cmake version (released in November 2016) that
introduced GREATER_EQUAL, which is used already.
Reported-by: nick-telia on github
Fixes#10128Closes#10161
I haven't had the time to check other configurations, but on my macOS
Ventura 13.1 with XCode 14.2 cmake does not find `snprintf`.
Solution: ensure stdio.h is checked for definitions
Closes#10155
CMAKE_*_LINKER_FLAGS must be a string but GSS_LINKER_FLAGS is a list, so
we need to replace semicolons with spaces when setting those.
Fixes#9017Closes#1022
`Curl_getaddrinfo_ex()` gets _defined_ with `HAVE_GETADDRINFO` set. But,
`hostip4.c` _used_ it with `HAVE_GETADDRINFO_THREADSAFE` set alone. It
meant a build with the latter, but without the former flag could result
in calling this function but not defining it, and failing to link.
Patch this by adding an extra check for `HAVE_GETATTRINFO` around the
call.
Before this patch, build systems prevented this condition. Now they
don't need to.
While here, simplify the related CMake logic on Windows by setting
`HAVE_GETADDRINFO_THREADSAFE` to the detection result of
`HAVE_GETADDRINFO`. This expresses the following intent clearer than
the previous patch and keeps the logic in a single block of code:
When we have `getaddrinfo()` on Windows, it's always threadsafe.
Follow-up to 67d88626d4
Reviewed-by: Jay Satiro
Closes#9734
This patch aims to cleanup the use of `process.h` header and the macro
`HAVE_PROCESS_H` associated with it.
- `process.h` is always available on Windows. In curl, it is required
only for `_beginthreadex()` in `lib/curl_threads.c`.
- `process.h` is also available in MS-DOS. In curl, its only use was in
`lib/smb.c` for `getpid()`. But `getpid()` is in fact declared by
`unistd.h`, which is always enabled via `lib/config-dos.h`. So the
header is not necessary.
- `HAVE_PROCESS_H` was detected by CMake, forced to 1 on Windows and
left to real detection for other platforms.
It was also set to always-on in `lib/config-win32.h` and
`lib/config-dos.h`.
In autotools builds, there was no detection and the macro was never
set.
Based on these observations, in this patch we:
- Rework Windows `getpid` logic in `lib/smb.c` to always use the
equivalent direct Win32 API function `GetCurrentProcessId()`, as we
already did for Windows UWP apps. This makes `process.h` unnecessary
here on Windows.
- Stop #including `process.h` into files where it was not necessary.
This is everywhere, except `lib/curl_threads.c`.
> Strangely enough, `lib/curl_threads.c` compiled fine with autotools
> because `process.h` is also indirecty included via `unistd.h`. This
> might have been broken in autotools MSVC builds, where the latter
> header is missing.
- Delete all remaining `HAVE_PROCESS_H` feature guards, for they were
unnecessary.
- Delete `HAVE_PROCESS_H` detection from CMake and predefined values
from `lib/config-*.h` headers.
Reviewed-by: Jay Satiro
Closes#9703
Even though `PICKY_COMPILER=ON` is the default, warnings were not
enabled when using llvm/clang, because `CMAKE_COMPILER_IS_CLANG` was
always false (in my tests at least).
This is the single use of this variable in curl, and in a different
place we already use `CMAKE_C_COMPILER_ID MATCHES "Clang"`, which works
as expected, so change the condition to use that instead.
Also fix the warnings uncovered by the above:
- lib: add casts to silence clang warnings
- schannel: add casts to silence clang warnings in ALPN code
Assuming the code is correct, solve the warnings with a cast.
This particular build case isn't CI tested.
There is a chance the warning is relevant for some platforms, perhaps
Windows 32-bit ARM7.
Closes#9783
`WANT_IDN_PROTOTYPES` was necessary to avoid using a header that came
via an optional package. MS stopped distributing this package some
years ago and the winidn definitions are part of standard headers (via
`windows.h`) since Vista.
Auto-detect Vista inside `lib/idn_win32.c` and enable the manual
definitions if building for an older Windows.
This allows to delete this manual knob from all build-systems.
Also drop the `_SAL_VERSION` sub-case:
Our manual definitions are now only enabled with old systems. We assume
that code analysis is not run on such systems, allowing us to delete the
SAL-friendly flavour of these.
Reviewed-by: Jay Satiro
Closes#9793
`lib/config-win32.h` enables this configuration option unconditionally.
Make it apply to CMake builds as well.
While here, delete a broken check for
`HAVE_SOCKADDR_IN6_SIN6_SCOPE_ID` from `CMakeLists.txt`. This came with
the initial commit [1], but did not include the actual verification code
inside `CMake/CurlTests.c`, so it always failed. A later commit [2]
added a second test, for non-Windows platforms.
Enabling this flag causes test 1056 to fail with CMake builds, as they
do with autotools builds. Let's apply the same solution and ignore the
results here as well.
[1] 4c5307b456
[2] aec7c5a87c
Reviewed-by: Daniel Stenberg
Assisted-by: Marcel Raad
Closes#9726
autotools enables this configuration option unconditionally for Windows
[^1]. Do the same in CMake.
The above will make this work for all reasonably recent environments.
The logic present in `lib/config-win32.h` [^2] has the following
exceptions which we did not cover in this CMake update:
- Builds targeting Windows 2000 and earlier
- MS Visual C++ 5.0 (1997) and earlier
Also make sure to disable this feature when `HAVE_GETADDRINFO` isn't
set, to avoid a broken build. We might want to handle that in the C
sources in a future commit.
[^1]: 68fa9bf3f5/m4/curl-functions.m4 (L2067-L2070)
[^2]: 68fa9bf3f5/lib/config-win32.h (L511-L528)Closes#9727
`HAVE_SIGNAL` means the availability of the `signal()` function in
autotools, while in CMake it meant the availability of that function
_and_ the symbol `SIGALRM`.
The latter is not available on Windows, but the function is, which means
on Windows, autotools did define `HAVE_SIGNAL`, but CMake did not,
introducing a slight difference into the binaries.
This patch syncs CMake behaviour with autotools to look for the function
only.
The logic came with the initial commit adding CMake support to curl, so
the commit history doesn't reveal the reason behind it. In any case,
it's best to check the existence of `SIGALRM` directly in the source
before use. For now, curl builds fine with `HAVE_SIGNAL` enabled and
`SIGALRM` missing.
Follow-up to 68fa9bf3f5Closes#9725
A custom `HAVE_GETADDRINFO` check came with the initial CMake commit
[1]. A later commit [2] added a standard check for it as well. The
standard check run before the custom one, so CMake ignored the latter.
The custom check was also non-portable, so this patch deletes it in
favor of the standard check.
[1] 4c5307b456
[2] aec7c5a87cCloses#9731
Enable `HAVE_UNISTD_H`, `HAVE_STRTOK_R` and `HAVE_STRCASECMP` detection
on Windows, instead of having predefined values.
With these features detected correctly, CMake Windows builds get closer
to the autotools and `config-win32.h` ones.
This also fixes detecting `HAVE_FTRUNCATE` correctly, which required
`unistd.h`.
Fixing `ftruncate()` in turn causes a build warning/error with legacy
MinGW/MSYS1 due to an offset type size mismatch. This env misses to
detect `HAVE_FILE_OFFSET_BITS`, which may be a reason. This patch
force-disables `HAVE_FTRUNCATE` for this platform.
Reviewed-by: Daniel Stenberg
Closes#9687
This adds the missing half of the check, next to the other half
already present in `lib/curl_config.h.cmake`.
Force disable `HAVE_INET_NTOP` for old MSVC where it caused compiler
warnings.
Reviewed-by: Daniel Stenberg
Closes#9689
Detecting headers and lib separately makes sense when headers come in
variations or with extra ones, but this wasn't the case here. These were
duplicate/parallel macros that we had to keep in sync with each other
for a working build. This patch leaves a single macro for each of these
dependencies:
- Rely on `HAVE_LIBZ`, delete parallel `HAVE_ZLIB_H`.
Also delete CMake logic making sure these two were in sync, along with
a toggle to turn off that logic, called `CURL_SPECIAL_LIBZ`.
Also delete stray `HAVE_ZLIB` defines.
There is also a `USE_ZLIB` variant in `lib/config-dos.h`. This patch
retains it for compatibility and deprecates it.
- Rely on `USE_LIBSSH2`, delete parallel `HAVE_LIBSSH2_H`.
Also delete `LIBSSH2_WIN32`, `LIBSSH2_LIBRARY` from
`winbuild/MakefileBuild.vc`, these have a role when building libssh2
itself. And `CURL_USE_LIBSSH`, which had no use at all.
Also delete stray `HAVE_LIBSSH2` defines.
- Rely on `USE_LIBSSH`, delete parallel `HAVE_LIBSSH_LIBSSH_H`.
Also delete `LIBSSH_WIN32`, `LIBSSH_LIBRARY` and `HAVE_LIBSSH` from
`winbuild/MakefileBuild.vc`, these were the result of copy-pasting the
libssh2 line, and were not having any use.
- Delete unused `HAVE_LIBPSL_H` and `HAVE_LIBPSL`.
Reviewed-by: Daniel Stenberg
Closes#9652
This header is for providing the argument types for recv() and send()
when built to not use a dedicated config-[platfor].h file.
Remove the slow brute-force checks from configure and cmake.
This change also removes the use of the types for select, as they were
not used in code.
Closes#9592
This is the single place in libcurl code where it uses the "native"
s(n)printf() function. Used for writing floats. The use has been
reviewed and vetted and uses a HUGE target buffer, but switching to
snprintf() still makes this safer and removes build-time warnings.
Reported-by: Philip Heiduck
Fixes#9569Closes#9570
CMake seems to be able to compare two hex values just fine.
Also make sure CURL_TARGET_WINDOWS_VERSION is respected.
Assisted-by: Marcel Raad
Reviewed-by: Viktor Szakats
Reported-by: Keitagit-kun on github
Follow up to #9312Fixes#9406Closes#9411
1. Re-enable `HAVE_GETADDRINFO` detection on Windows
Commit d08ee3c83d (in 2013) added logic
that automatically assumed `getaddrinfo()` to be present for builds
with IPv6 enabled. As it turns out, certain toolchains (e.g. original
MinGW) by default target older Windows versions, and thus do not
support `getaddrinfo()` out of the box. The issue was masked for
a while by CMake builds forcing a newer Windows version, but that
logic got deleted in commit 8ba22ffb20.
Since then, some CI builds started failing due to IPv6 enabled,
`HAVE_GETADDRINFO` set, but `getaddrinfo()` in fact missing.
It also turns out that IPv6 works without `getaddrinfo()` since commit
67a08dca27 (from 2019, via #4662). So,
to resolve all this, we can now revert the initial commit, thus
restoring `getaddrinfo()` detection and support IPv6 regardless of its
outcome.
Reported-by: Daniel Stenberg
2. Omit `bcrypt` with original MinGW
Original (aka legacy/old) MinGW versions do not support `bcrypt`
(introduced with Vista). We already have logic to handle that in
`lib/rand.c` and autotools builds, where we do not call the
unsupported API and do not link `bcrypt`, respectively, when using
original MinGW.
This patch ports that logic to CMake, fixing the link error:
`c:/mingw/bin/../lib/gcc/mingw32/9.2.0/../../../../mingw32/bin/ld.exe: cannot find -lbcrypt`
Ref: https://ci.appveyor.com/project/curlorg/curl/builds/44624888/job/40vle84cn4vle7s0#L508
Regression since 76172511e7Fixes#9214Fixes#9393Fixes#9395Closes#9396
Avoids failing test 1014 by replicating configure checks
for HAVE_ATOMIC and _WIN32_WINNT with custom CMake tests.
Reviewed-by: Marcel Raad
Follow up to #8680Closes#9312
This patch makes CMake fill the "OS string" with the value of
`CMAKE_C_COMPILER_TARGET`, if passed. This typically contains a triplet,
the same we can pass to `./configure` via `--host=`.
For non-CMake, non-autotools, Windows builds, this patch adds the ability
to override the default `OS` value in `lib/config-win32.h`.
With these its possible to get the same OS string across the three build
systems.
This patch supersedes the earlier, partial, CMake-only solution:
435f395f3f, thus retiring the
`CURL_OS_SUFFIX` CMake option.
Reviewed-by: Jay Satiro
Closes#9117
Update the ngtcp2 find module to detect the boringssl backend. Determine
if the underlying OpenSSL implementation is BoringSSL and if so use that
as the ngtcp2 backend.
Reviewed-by: Jakub Zakrzewski
Closes#9065
The goal of this patch is to avoid CMake forcing specific Windows
versions and rely on toolchain defaults or manual selection instead.
This gives back control to the user. This also brings CMake closer to
how autotools and `Makefile.m32` behaves in this regard.
- CMake had a setting `ENABLE_INET_PTON` defaulting to `ON`, which did
nothing else than fixing the Windows build target to Vista. This also
happened when the toolchain did not have Vista support (e.g. original
MinGW), breaking such builds.
In other environments it did not make a user-facing difference,
because libcurl has its own pton() implementation, so it works well
with or without Vista's inet_pton().
This patch drops this setting. inet_pton() is now used whenever
building for Vista or newer, either when requested manually or by
default with modern toolchains (e.g. mingw-w64). Older envs will fall
back to curl's pton().
Ref: https://github.com/curl/curl/pull/9027#issuecomment-1164157604
Ref: https://github.com/curl/curl/pull/8997#issuecomment-1164344155
- When the user did no select a Windows target version manually, stop
explicitly targeting Windows XP, and instead use the toolchain default.
This may pose an issue with old toolchains defaulting to pre-XP
targets. In such case you must manually target Windows XP via:
`-DCURL_TARGET_WINDOWS_VERSION=0x0501`
or
`-DCMAKE_C_FLAGS=-D_WIN32_WINNT=0x0501`
Reviewed-by: Jay Satiro
Reviewed-by: Marcel Raad
Closes#9046
- Use the Windows API to seed the fallback random generator.
This ensures to always have a random seed, even when libcurl is built
with a vtls backend lacking a random generator API, such as rustls
(experimental), GSKit and certain mbedTLS builds, or, when libcurl is
built without a TLS backend. We reuse the Windows-specific random
function from the Schannel backend.
- Implement support for `BCryptGenRandom()` [1] on Windows, as a
replacement for the deprecated `CryptGenRandom()` [2] function.
It is used as the secure random generator for Schannel, and also to
provide entropy for libcurl's fallback random generator. The new
function is supported on Vista and newer via its `bcrypt.dll`. It is
used automatically when building for supported versions. It also works
in UWP apps (the old function did not).
- Clear entropy buffer before calling the Windows random generator.
This avoids using arbitrary application memory as entropy (with
`CryptGenRandom()`) and makes sure to return in a predictable state
when an API call fails.
[1] https://docs.microsoft.com/windows/win32/api/bcrypt/nf-bcrypt-bcryptgenrandom
[2] https://docs.microsoft.com/windows/win32/api/wincrypt/nf-wincrypt-cryptgenrandomCloses#9027
