cmake: make Threads package optional #354

ryanofsky commented at 8:42 PM on August 20, 2026: collaborator

Make find_package(Threads) optional because there are platforms where this package may not be required, and because find_package(Threads REQUIRED) errors obscure more detailed error messages and make issues harder to debug.

There errors can happen on different platforms with different cmake policy settings. See commit message for details.

cmake: make Threads package optional

Make find_package(Threads) optional because there are platforms where
this package may not be required, and because find_package(Threads
REQUIRED) errors obscure more detailed error messages and makes issues
harder to debug.

For example with CMP0155 enabled which turns CMAKE_CXX_SCAN_FOR_MODULES
on, find_package(Threads) fails on freebsd and openbsd CI jobs which
lack a clang-scan-deps tool. Also when CMP0137 is disabled or
CMAKE_TRY_COMPILE_NO_PLATFORM_VARIABLES is set to true
find_package(Threadss) fails in the llvm CI job. This change lets builds
in both of those cases succeed.

The freebsd CMP0155 error looks like:

 + cmake /home/runner/work/libmultiprocess/libmultiprocess -G Ninja
-- The CXX compiler identification is Clang 16.0.6
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Failed
-- Looking for pthread_create in pthreads
-- Looking for pthread_create in pthreads - not found
-- Looking for pthread_create in pthread
-- Looking for pthread_create in pthread - not found
-- Check if compiler accepts -pthread
-- Check if compiler accepts -pthread - no
CMake Error at /usr/local/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:233 (message):
  Could NOT find Threads (missing: Threads_FOUND)
Call Stack (most recent call first):
  /usr/local/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:603 (_FPHSA_FAILURE_MESSAGE)
  /usr/local/share/cmake/Modules/FindThreads.cmake:226 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
  CMakeLists.txt:41 (find_package)

Inside the CMakeConfigureLog.yaml file there are "/bin/sh:
CMAKE_CXX_COMPILER_CLANG_SCAN_DEPS-NOTFOUND: not found" errors.

45c7dca6a5

DrahtBot commented at 8:42 PM on August 20, 2026: none

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Reviews

See the guideline and AI policy for information on the review process. A summary of reviews will appear here.

Conflicts

Reviewers, this pull request conflicts with the following ones:

#342 (Allow request cancellation for wrapped C++ methods by xyzconstant)

If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

maflcko commented at 6:28 AM on August 21, 2026: contributor

~0: Same here. This won't happen in reality on current master, so better to leave in https://github.com/bitcoin-core/libmultiprocess/pull/209

in CMakeLists.txt:20 in 45c7dca6a5

  16 | +add_library(mpdeps INTERFACE)
  17 | +
  18 | +find_package(Threads)
  19 | +if(Threads_FOUND)
  20 | +  target_link_libraries(mpdeps INTERFACE Threads::Threads)
  21 | +endif()

hebasto commented at 11:50 AM on August 23, 2026:

Make find_package(Threads) optional because there are platforms where this package may not be required...

But the code does not look platform-dependent.

According to the docs, FindThreads is capable of figuring out:

... if the thread functions are provided by the system libraries and no special flags are needed to use them.

Therefore, I don't see this change is necessary.

ryanofsky commented at 3:26 AM on August 26, 2026:

re: #354 (review)

According to the docs, FindThreads is capable of figuring out

The docs are wrong. The REQUIRED keyword here hides useful error messages and replaces them with misleading "Could NOT find Threads" messages. This has happened to me on multiple occasions as described in the commit message and misled me and wasted my time.

If you think there is an advantage REQUIRED provides here, it would be good to know what it is. The only thing I see REQUIRED doing here is replacing real errors with fake and misleading ones. It seems clear to me find_package(Threads) is a helpful way to add thread dependencies and find_package(Threads REQUIRED) is a footgun.

re: #354 (comment)

This won't happen in reality on current master

That's a bold prediction! It does not happen on current master, but it happened to me twice on different occasions changing the policy version and can easily happen with changes to platforms, toolchain files or any of the spaghetti code module files distributed with cmake.

purpleKarrot commented at 7:20 AM on August 26, 2026:

The docs are wrong.

Is there something we can report upstream? Can you share the situation and output of the suppressed diagnostics?

hebasto commented at 7:05 AM on August 26, 2026: member

cc @purpleKarrot

maflcko commented at 7:06 AM on August 26, 2026: contributor

This won't happen in reality on current master

That's a bold prediction! It does not happen on current master, but it happened to me twice on different occasions changing the policy version and can easily happen with changes to platforms, toolchain files or any of the spaghetti code module files distributed with cmake.

Ok, what I wanted to say was that this doesn't practically happen in reality. Someone changing the policy isn't something a real end-user does, but more a dev-only thing. The dev should know what they are doing, and should know what they are signing up for, so I don't think it makes sense to accommodate for that outside the pull that changes the policy version.

If this can easily happen in reality on a platform, it would be good to know the platform.