<div dir="ltr"><div dir="ltr">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).<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Mar 10, 2021 at 11:27 PM Martin Storsjö via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
On Thu, 11 Mar 2021, Shoaib Meenai via llvm-dev wrote:<br>
<br>
> What’s happening is that the configuration for the builtins for Android <br>
> tests for all supported architectures [1], using check_symbol_exists to <br>
> check for the architecture’s preprocessor macro [2]. check_symbol_exists <br>
> tries to link a test executable, which fails because my just-built <br>
> compiler doesn’t have compiler-rt yet (since it’s trying to build <br>
> compiler-rt). Consequently, the builtins don’t think that any <br>
> architectures are supported, and just don’t build anything as a result.<br>
> <br>
>  <br>
> <br>
> Other places in the builtins’ CMake logic use custom functions like<br>
> try_compile_only to only test compilation and not linking, to avoid issues<br>
> like this. My understanding is that the builtins will never be built as<br>
> shared libraries. The build already instructs its custom test macros to<br>
> always only check compilation [3]; now that we’re on a newer CMake version,<br>
> would it be appropriate to always set CMAKE_TRY_COMPILE_TARGET_TYPE to<br>
> STATIC_LIBRARY for the builtins as well, so that all CMake checks build<br>
> static libraries (which has the same effect of only testing compilation and<br>
> not linking)? We could also probably clean up a lot of the custom logic for<br>
> only checking compilation afterwards.<br>
<br>
These kinds of chicken-and-egg problems are all over building the <br>
runtimes, and when building the initial copy of runtime libraries, there's <br>
some amount of trickery needed to pass such tests.<br>
<br>
In most of the cases where I build runtimes, I've had to add <br>
-DCMAKE_C_COMPILER_WORKS=TRUE -DCMAKE_CXX_COMPILER_WORKS=TRUE, but iirc <br>
one of such cases for compiler-rt could be removed if we'd set <br>
CMAKE_TRY_COMPILE_TARGET_TYPE to STATIC_LIBRARY. (For <br>
libunwind/libcxxabi/libcxx, things were more complicated though, I think.)<br>
<br>
I actually sent a patch to this effect a couple months ago, have a look at <br>
[1]. That one was only aimed at standalone builds of <br>
compiler-rt/lib/builtins, but maybe it could be generalized to some other <br>
location as well. For non-standalone builds, I guess the option would have <br>
to be cleared after processing the current project?<br>
<br>
// Martin<br>
<br>
[1] <a href="https://reviews.llvm.org/D91334" rel="noreferrer" target="_blank">https://reviews.llvm.org/D91334</a><br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div></div>