Since commit d74210a8bd (CMP0017: Remove support for OLD behavior,
2024-11-17) we can rely on CMP0017's NEW behavior unconditionally.
Calling `include(FindPackageHandleStandardArgs)` in a builtin module
will always get the builtin `FindPackageHandleStandardArgs`.
`try_compile` and `try_run` now automatically log checks using them to
`CMakeConfigureLog.yaml`.
Add `LOG_DESCRIPTION` arguments to some `try_compile` calls to
replace the description previously written to the old logs.
Issue: #23200
Modify some modules that ship with CMake to use the new SOURCES_FROM_*
arguments to try_compile / try_run as added by commits cb14ae2b87
(try_compile: Add SOURCE_FROM_{ARG,VAR}, 2022-09-21) and 611d801790
(try_compile: Add SOURCE_FROM_FILE, 2022-09-22). This covers users which
previously either used an existing file (but sometimes needed to rename
it), or which wrote out their source in entirety. It does NOT cover
users that actually need configure_file functionality, as those will be
more involved to update and will thus be tackled in part 2.
Modify most of the modules that ship with CMake to use the new
try_compile / try_run signatures added by commit aa9220d3a0
(try_compile: Add keyword-dispatched signature, 2022-09-02). This
improves debugging by each invocation using its own directory so that
the results of multiple invocations can be retained.
This does not cover any invocations which provide an entire project, as
that flavor of try_compile has not yet been updated.
Since commit 3257c34073 (FindThreads: avoid failing in AIX when using
-D_XOPEN_SOURCE=500, 2022-04-30, v3.24.0-rc1~197^2) we no longer check
for `pthreads.h` before checking for the `-pthread` flag. Compilers
targeting the MSVC ABI do not have such a flag, so avoid performing the
check unnecessarily.
Fixes: #23829
Current FindThreads fails in AIX (tested on 7.1 and 7.2) when using
additional compilation flags (ex: -D_XOPEN_SOURCE=500) because the
linker might need additional flags to link and those aren't yet known
by the time check_include("pthread.h") is run (which is also the first
test).
Remove the check for it and all supporting code and rely instead on
the compilation test that will be done later to find the correct
syntax to use, and that confirms it exists implicitly.
The `THREADS_HAVE_PTHREAD_ARG` cache entry cannot be defined unless
FindThreads has already been executed, perhaps by a previous run of
CMake, or a previous `find_package(Threads)` call. In that case, the
other alternatives will also already have been checked and results
cached.
This internal variable has not been used since commit 46368eddfd
(FindThreads: move checking of the -pthread compiler flag into a macro,
2014-10-06, v3.1.0-rc1~21^2~2). It has never been documented for public
use.
Revert commit 5efb6fb516 (FindThreads: Honor THREADS_PREFER_PTHREAD_FLAG
when pthread is found in libc, 2021-11-03, v3.21.5~4^2). The check for
the `-pthread` flag can pass on compilers like XL, that interprets it as
`-p -t hread` and returns zero. Prior to that commit, we did not use
the check in the `CMAKE_HAVE_LIBC_PTHREAD` code path. Now we do, it
succeeds, and we incorrectly add the `-pthread` flag for XL.
This change was backported to the 3.21 and 3.22 release series long
after they initially came out. Since there may be more cases where we
now add `-pthread` incorrectly, it is simplest to revert the change in
all release series pending further investigation.
Fixes: #23270
The `-pthread` flag tells the compiler/linker to link to additional
libraries needed for thread support (e.g. libatomic on riscv64). The
flag therefore should be used if requested using
`THREADS_PREFER_PTHREAD_FLAG` also when the pthread functions are
found in libc.
The `-pthread` flag tells the compiler/linker to link to additional
libraries needed for thread support (e.g. libatomic on riscv64). The
flag therefore should be used if requested using
`THREADS_PREFER_PTHREAD_FLAG` also when the pthread functions are
found in libc.
When a CMake based project fails, users start looking at
CMakeError.log and think that the FindThread output is
the problem, but it is a false positive.
Now FindThreads only logs to `CMakeError.log` when it fails
to find a suitable flag, reducing the amount of false positives in `CMakeError.log`.
Fixes#16540, Fixes#19344
When CMAKE_C_FLAGS contains '-Werror -Wmissing-prototypes'
the pthread test code check fails with error:
"src.c:3:7: error: no previous prototype for 'test_func' [-Werror=missing-prototypes]".
Adding 'static' keyword to 'test_func' fixes it.
Currently CMake passes `-Xcompiler -pthread` flags to CUDA compilers
irrespective of the actual CUDA compiler ID. This makes sure the
additional `-Xcompiler` flag is only used with nvcc.
When using ThreadSanitizer our existing CMAKE_HAVE_LIBC_PTHREAD test
program links using symbols from the tsan library. Among the symbols
not provided by that library, `pthread_cancel()` seems to be the less
risky symbol to add to the check.
Fixes: #19981
Revert commit de5f123d3a (FindThreads: Do not hard-code '-l' flag on
library name, 2019-09-23, v3.16.0-rc1~71^2). Some clients depend
on the value of `CMAKE_THREAD_LIBS_INIT` to contain a valid flag.
Fixes: #20061, #20065
When not using the `-pthread` flag we instead return a library to link
by name. Previously we hard-coded the `-l` flag before the library
name. When used with `target_link_libraries`, the hard-coded `-l` flag
is preserved rather than transformed into the link option preferred by
the toolchain in use. Drop the explicit `-l` part to let CMake's
generators produce the proper way to link the threads library for the
current toolchain.
Fixes: #19747
Drop the sentence added by commit 5a5a1d90f0 (Help: FindThreads not
needed with modern C++., 2019-01-09, v3.14.0-rc1~186^2) about not
needing the module with modern C++. The module is often still needed.
Fixes: #19297
Our check for just `pthread_create` is not sufficient because there are
cases where that symbol may be found in libc but not all of pthreads.
We first tried to address this in commit e9a1ddc594 (FindThreads:
Replace the pthread symbol checking in libc., 2018-11-18,
v3.14.0-rc1~292^2) by switching to `pthread_kill`, but that had to be
reverted by commit 18320230ec (FindThreads: Revert libc symbol check to
pthread_create, 2019-02-27, v3.14.0-rc3~6^2) because there are other
cases where `pthread_kill` is in libc but the rest of pthreads is not.
Update our check to try a complete program using pthreads as an actual
application might.
Fixes: #18994
Since commit e9a1ddc594 (FindThreads: Replace the pthread symbol
checking in libc., 2018-11-18, v3.14.0-rc1~292^2) we check libc for
`pthread_kill` instead of `pthread_create`. However, on FreeBSD
`pthread_kill` is in libc but not `pthread_create`. Discussion in the
original merge request for the above commit also considered
`pthread_key_create`, `pthread_self`, and `pthread_attr_init`. Every
symbol seems to have some reason it is not an appropriate choice.
Revert to the pre-3.14 behavior of using `pthread_create` pending
further investigation.
In commit e9a1ddc594 (FindThreads: Replace the pthread symbol checking
in libc., 2018-11-18, v3.14.0-rc1~292^2) we switched to checking for
`pthread_kill` in libc but did not update the symbol check's header file
to match. Add `signal.h` to get `pthread_kill`. Keep `pthread.h`
anyway since the purpose of the check is to verify that the pthread API
works.
Fixes: #18984
We do not need to support IRIX anymore, so drop relevant parts. In
particular, the `CMAKE_THREAD_PREFER_PTHREAD` is frequently confused
with `THREADS_PREFER_PTHREAD_FLAG`.
Also remove references to the IRIX-specific options and results
from other modules and tests.
With asan build, we will have the pthread_create() symbol in libc. However,
libasan doesn't have full pthread implementation. We can't assume that we
have the pthread implementation in libc using pthread_create() symbol.
Replace the pthread_create() with pthread_kill() as a quick fix.
2cc050b53b CUDA: Add test for device linking when host linking uses threads
83c13ca44f FindThreads: Pass -pthread to CUDA compiler through -Xcompiler
cf92fd9ae9 Merge branch 'cuda-filter-device-link-items' into cuda-thread-flags
e768d96c74 CUDA: Filter out host link flags during device linking
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Kelly (KT) Thompson <kgt@lanl.gov>
Merge-request: !2512
Use `try_compile` instead of `try_run`. It is not clear why `try_run`
was ever needed, and it does not work during cross-compiling.
Update the check's source file to remove code associated with actually
running things. Also remove the ancient `__CLASSIC_C__` code path and
use a simple `int main(void)` as in `Modules/CheckIncludeFile.c.in`.
Fixes: #16920
Per-source copyright/license notice headers that spell out copyright holder
names and years are hard to maintain and often out-of-date or plain wrong.
Precise contributor information is already maintained automatically by the
version control tool. Ultimately it is the receiver of a file who is
responsible for determining its licensing status, and per-source notices are
merely a convenience. Therefore it is simpler and more accurate for
each source to have a generic notice of the license name and references to
more detailed information on copyright holders and full license terms.
Our `Copyright.txt` file now contains a list of Contributors whose names
appeared source-level copyright notices. It also references version control
history for more precise information. Therefore we no longer need to spell
out the list of Contributors in each source file notice.
Replace CMake per-source copyright/license notice headers with a short
description of the license and links to `Copyright.txt` and online information
available from "https://cmake.org/licensing". The online URL also handles
cases of modules being copied out of our source into other projects, so we
can drop our notices about replacing links with full license text.
Run the `Utilities/Scripts/filter-notices.bash` script to perform the majority
of the replacements mechanically. Manually fix up shebang lines and trailing
newlines in a few files. Manually update the notices in a few files that the
script does not handle.
While at it, also add a branch using CheckIncludeFileCXX. Also give a better
error message if no supported language is enabled. C++ support isn't working
yet, but it has never worked.
