[libcxx-commits] [PATCH] D113253: [runtimes] Fix building initial libunwind+libcxxabi+libcxx with compiler implied -lunwind

Martin Storsjö via Phabricator via libcxx-commits libcxx-commits at lists.llvm.org
Thu Dec 9 11:37:09 PST 2021


mstorsjo added a comment.

In D113253#3183450 <https://reviews.llvm.org/D113253#3183450>, @phosek wrote:

> This fails:
>
>   set(CMAKE_TRY_COMPILE_TARGET_TYPE STATIC_LIBRARY)
>   project(Runtimes)
>   set(CMAKE_TRY_COMPILE_TARGET_TYPE EXECUTABLE)
>   cmake_minimum_required(VERSION 3.10)
>   find_package(ZLIB)
>
> This succeeds:
>
>   project(Runtimes)
>   cmake_minimum_required(VERSION 3.10)
>   set(CMAKE_TRY_COMPILE_TARGET_TYPE STATIC_LIBRARY)
>   find_package(ZLIB)
>   set(CMAKE_TRY_COMPILE_TARGET_TYPE EXECUTABLE)
>
> So it seems like this is somehow related to the `project` configuration rather than the `find_package` implementation.

Yeah - or even more precisely, it's related to `enable_languages`, as this snippet also should reproduce the same issue based on my experience so far:

  project(Runtimes LANGUAGES NONE)
  set(CMAKE_TRY_COMPILE_TARGET_TYPE STATIC_LIBRARY)
  enable_language(C)
  set(CMAKE_TRY_COMPILE_TARGET_TYPE EXECUTABLE)
  find_package(ZLIB)

I think the reason is that when probing the compiler, it normally detects things like the target triple and directories that the compiler normally looks in when linking (e.g. `/usr/lib/x86_64-linux-gnu`) which then are used for finding libraries.

Anyway, I'll go ahead and reland this patch without those bits, to move forward somewhat. I can live without them, even if would be neat if we could avoid needing things like setting `CMAKE_C_COMPILER_WORKS=YES`.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D113253/new/

https://reviews.llvm.org/D113253



More information about the libcxx-commits mailing list