[all-commits] [llvm/llvm-project] 8537a9: [GTest] Change detection of libpthread

[nemanja-ibm via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 8537a99b2c1d08e9e586b3fb9e36728075ec4a03
      https://github.com/llvm/llvm-project/commit/8537a99b2c1d08e9e586b3fb9e36728075ec4a03
  Author: Nemanja Ivanovic <nemanjai at ca.ibm.com>
  Date:   2022-08-22 (Mon, 22 Aug 2022)

  Changed paths:
    M llvm/utils/unittest/CMakeLists.txt

  Log Message:
  -----------
  [GTest] Change detection of libpthread

We currently use CMake's find_library function to detect whether
libpthread exists on the system to determine if pthread should
be added on the link step. However, there are configurations in
which CMake's path checking fails to find the library even though
the toolchain has it.

One such case is with Clang 14.0.0 on PowerPC. Due to a recent
change, the build puts libc++ and related libraries in a
subdirectory that appears to depend on the default target triple.
CMake then uses that subdirectory to determine the architecture
and adds that name to its search paths. However, the triple for
the system GNU toolchain is different so CMake fails to find it.
Namely, Clang 14.0.0's default target triple and the subdirectory
name is powerpc64le-unknown-linux-gnu whereas the system GNU
toolchain has powerpc64le-linux-gnu. Clang's driver has no trouble
finding either the GNU includes/libraries or Clang's own. But
CMake seems to get this wrong.

The net result of this is that we can't do a shared libraries
build of ToT with Clang 14.0.0.

This patch proposes using HAVE_LIBPTHREAD which CMake seems to
determine by compiling a test file with -lpthread (or perhaps
-pthread, I can't really get CMake to tell me how it is figuring
this out). If that variable tells CMake that the build compiler
accepts the pthread option, it seems reasonable to depend on
that variable to determine if we should add it to the link step
when building the llvm_gtest library.