[llvm-dev] Should the compiler-rt builtins be configured with CMAKE_TRY_COMPILE_TARGET_TYPE?

[Martin Storsjö via llvm-dev]

On Wed, 10 Mar 2021, Petr Hosek wrote:

> I was actually wondering if we could go further and set this not just for
> builtins but also for the runtimes build. In the runtimes build, we link
> shared libraries like libunwind, libc++abi, libc++ and some of the
> sanitizers, but it's not clear to me if this would cause any issues. We have
> a few check_library_exists calls but most of them are checking libraries
> like libc, libm, libdl, librt? Even C libraries that don't provide these as
> separate libraries like musl typically provide linker scripts for backwards
> compatibility. Would any of the currently supported platforms break if we
> started linking those libraries unconditionally? Alternatively, we could
> also consider replacing the use of -nodefaultlibs with -nostdlib++ and
> letting the compiler driver handle this, but GCC as far as I'm aware doesn't
> yet support that flag so we would need a fallback (we could set
> CMAKE_TRY_COMPILE_TARGET_TYPE to STATIC_LIBRARY and -nostdlib++ only for
> Clang, and keeping the existing behavior for GCC, but it might increase the
> complexity).

I remember testing setting CMAKE_TRY_COMPILE_TARGET_TYPE to STATIC_LIBRARY 
for libunwind/libcxxabi/libcxx a couple months ago so that I could lose 
the hardcoded CMAKE_C_COMPILER_WORKS=TRUE and 
CMAKE_CXX_COMPILER_WORKS=TRUE, but it didn't work flawlessly. I don't 
remember the exact details, but I think it was in the form of lots of 
tests succeeding while they shouldn't.

As for libc/libm/librt/libdl, windows has none of those.

Overall regarding -nostdlib++, that one generally is much neater than 
-nodefaultlibs, but e.g. if running in a setup with -unwindlib=libunwind, 
that still tries to link in libunwind, which may be missing at that point.

// Martin