[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