FindThreads: 3.23.0-rc2 regression for XL toolchains
Odd behavior with XL toolchains
When doing a try_compile
with the XL toolchain, passing in -pthread
as a flag [relevant usage in FindThreads.cmake
], XL actually returns zero (success), interpreting it as equivalent to -p -t hread
. The result is not "using pthread" as such. It's actually an assortment of a profile-enabled build and nonsense (the -t
is used to modify a -B
flag and the hread
options to -t
aren't valid).
It's surprising that XL returns zero in this case, but it does.
Change in CMake behavior
Starting with this commit included with CMake 3.23.0-rc2, when THREADS_PREFER_PTHREAD_FLAG
is set, FindThreads.cmake
starts looking for support for -pthread
with that sort of try_compile
invocation. Based on a zero exit code from try_compile
, CMAKE_THREAD_LIBS_INIT
is initialized with -pthread
, which is an invalid flag for the XL toolchain.
THREADS_PREFER_PTHREAD_FLAG
Use of For instance, using GTestConfig.cmake
with XL results in this use case:
-
This bit uses
FindThreads.cmake
to deduce whetherGTestConfig.cmake
can assumepthread
is available. -
This bit sets
THREADS_PREFER_PTHREAD_FLAG
based on that information.
Note the lack of conditional checking for the OS or toolchain. THREADS_PREFER_PTHREAD_FLAG
runs on all toolchains and platforms.
Analysis
This small adjustment in how try_compile
is leveraged to detect pthreads is technically a regression compared to only looking for the existence of libraries that resemble a pthreads library. FindThreads
docs aren't 100% clear on the subject, but they seem to imply that CMAKE_THREAD_LIBS_INIT
should be empty in this situation.
If it's a desirable change, it should probably be added to the release notes. That will let me know that we should look to patch googletest
, etc., to not set THREADS_PREFER_PTHREAD_FLAG
on XL. Though it would be cleaner to have an explicit mechanism to mark a toolchain as explicitly not supporting pthreads -- a cache variable I could set in a toolchain file for instance.