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
- Change normaliz lib name to all lowercase.
This is from a standing patch in vcpkg:
Mingw has libnormaliz.a. For case-sensitive file systems (e.g. cross
builds from Linux), the spelling must match exactly.
Closes https://github.com/curl/curl/pull/9084
- Prevent CMake to auto-detect /dev/urandom when cross-building.
Before this patch, it would detect it in a cross-build scenario on *nix
hosts with this device present. This was a problem for example with
Windows builds, but it could affect any target system with this device
missing. This also syncs detection behaviour with autotools, which also
skips it for cross-builds.
- Also, make sure to never use the file RANDOM_FILE as entropy for libcurl's
fallback random number generator on Windows. Windows does not have the
concept of reading a random stream from a filename, nor any guaranteed
non-world-writable path on disk. With this, a manual misconfiguration or
an overeager auto-detection can no longer result in a user-controllable
seed source.
Reviewed-by: Daniel Stenberg
Closes#9038
Add licensing and copyright information for all files in this repository. This
either happens in the file itself as a comment header or in the file
`.reuse/dep5`.
This commit also adds a Github workflow to check pull requests and adapts
copyright.pl to the changes.
Closes#8869
CMake automatically uses the `CMAKE_SYSTEM_NAME` value to fill the OS
string appearing in the --version output after the curl version number,
for example:
'curl 7.83.1 (Windows)'
This patchs adds the ability to pass a suffix that is appended to this
value. It's useful to add CPU info or other platform details,
for example:
'curl 7.83.1 (Windows-x64)'
Closes#8919
Without this patch, libidn2 detection doesn't even seem to be
attempted. With this patch, cmake can be configured to pick it
up and enable it. Necessary configuration remains manual and
differs from most other dependencies.
If you are aware of a better fix, we're glad hearing about it
in a new Issue.
Closes#8917
To avoid the "... is deprecated" warnings brought by OpenSSL v3.
(We need to address the underlying code at some point of course.)
Assisted-by: Jakub Zakrzewski
Closes#7767
Adds the full listing of CURL_DISABLE options to the CMake build. Moves
all option code, except for CURL_DISABLE_OPENSSL_AUTO_LOA_CONFIG which
resides near OpenSSL configuration, to the same block of code. Also
sorts the options here and in the cmake config header.
Additionally sorted the CURL-DISABLE listing and fixed the
CURL_DISABLE_POP3 option.
Closes#7624
The values for HTTP_ONLY differed between CMakeLists.txt and
curl_setup.h. Sync them and sort the values in curl_setup.h to make it
easier to spot differences.
Closes#7601
Move the definition of sockaddr_un struct from config-win32.h to
curl_setup.h, so that it could be shared by all build systems.
Add ADDRESS_FAMILY typedef for old mingw, now old mingw can also use
unix sockets.
Also fix the build of tests/server/sws.c on Win32 when USE_UNIX_SOCKETS
is defined.
Closes#7034
From Apples documentation on SCDynamicStoreCopyProxies, "Return Value: A
dictionary of key-value pairs that represent the current internet proxy
settings, or NULL if no proxy settings have been defined or if an error
occurred. You must release the returned value."
Failure to release the returned value of SCDynamicStoreCopyProxies can
result in a memory leak.
Source: https://developer.apple.com/documentation/systemconfiguration/1517088-scdynamicstorecopyproxiesCloses#7265
The `find_libarary` command resolves the library or framework
into an absolute path. In case of system frameworks which are
located within an Xcode-provided SDK this results in the Xcode
path and SDK version being part of the library path.
Because those library paths end up in the exported CMake config
importing curl will fail once the Xcode location or SDK version
changes:
```cmake
set_target_properties(CURL::libcurl PROPERTIES
INTERFACE_INCLUDE_DIRECTORIES "${_IMPORT_PREFIX}/include"
INTERFACE_LINK_LIBRARIES "lber;ldap;/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.3.sdk/System/Library/Frameworks/SystemConfiguration.framework;OpenSSL::SSL;OpenSSL::Crypto;ZLIB::ZLIB"
)
```
A work-around is to link against system-level frameworks with
`-framework XYZ`. In case of `SystemConfiguration` we might be able
to omit the lookup-check because we could assume the framework is
always present.
Closes#7152
install(EXPORT ...) causes trouble when embedding curl dependencies
which don't provide install(EXPORT ...) targets (e.g libressl and
nghttp2) with cmake's add_subdirectory.
Reviewed-by: Jakub Zakrzewski
Closes#7060
Multithreaded compilation has been supported since at least VS 2005 and
been robustly stable since at least VS 2008
Closes https://github.com/curl/curl/pull/7109
... as they're checked for in the configure script and are used by
source code.
Removed checks for perror, setvbuf and strlcat since those defines are
not checked for in source code.
Bonus: removed HAVE_STRLCPY from a few config-*.h files since that
symbol is not used in source code.
Closes#6997
This was previously defined by the obsolete AC_TYPE_SIGNAL macro,
which was removed in 2682e5f5. The deprecation text says
> Your code may safely assume C89 semantics that RETSIGTYPE is void.
So, remove it and just use void instead.
Closes#6861
Avoid enabling NTLM feature based upon Windows SSPI
being enabled in case that crypto auth is disabled.
Reported-by: Marcel Raad
Follow-up to #6277Fixes#6803Closes#6808
Align conditions for NTLM features between CMake and configure
builds by differentiating between USE_NTLM and USE_CURL_NTLM_CORE,
just like curl_setup.h does internally to detect support of:
- USE_NTLM: required for NTLM crypto authentication feature
- USE_CURL_NTLM_CORE: required for SMB protocol
Implement USE_WIN32_CRYPTO detection by checking for Crypt functions
in wincrypt.h which are not available in the Windows App environment.
Link advapi32 and crypt32 for Crypto API and Schannel SSL backend.
Fix condition of Schannel SSL backend in CMake build accordingly.
Reviewed-by: Marcel Raad
Closes#6277
