llvm dev - Mar 2021 - Should the compiler-rt builtins be configured with CMAKE_TRY_COMPILE_TARGET_TYPE?

https://reviews.llvm.org/D96404 landed recently to default Android targets to
using compiler-rt instead of libgcc. Amusingly enough, it broke our builds of
compiler-rt for Android in the runtimes build setup. What’s happening is that
the configuration for the builtins for Android tests for all supported
architectures [1], using check_symbol_exists to check for the architecture’s
preprocessor macro [2]. check_symbol_exists tries to link a test executable,
which fails because my just-built compiler doesn’t have compiler-rt yet (since
it’s trying to build compiler-rt). Consequently, the builtins don’t think that
any architectures are supported, and just don’t build anything as a result.

Other places in the builtins’ CMake logic use custom functions like
try_compile_only to only test compilation and not linking, to avoid issues like
this. My understanding is that the builtins will never be built as shared
libraries. The build already instructs its custom test macros to always only
check compilation [3]; now that we’re on a newer CMake version, would it be
appropriate to always set CMAKE_TRY_COMPILE_TARGET_TYPE to STATIC_LIBRARY for
the builtins as well, so that all CMake checks build static libraries (which has
the same effect of only testing compilation and not linking)? We could also
probably clean up a lot of the custom logic for only checking compilation
afterwards.

[1]
https://github.com/llvm/llvm-project/blob/c7712087cbb505d324e1149fa224f607c91a8c6a/compiler-rt/cmake/base-config-ix.cmake#L164-L167
[2]
https://github.com/llvm/llvm-project/blob/c7712087cbb505d324e1149fa224f607c91a8c6a/compiler-rt/cmake/Modules/CompilerRTUtils.cmake#L155-L170
[3]
https://github.com/llvm/llvm-project/blob/c7712087cbb505d324e1149fa224f607c91a8c6a/compiler-rt/cmake/builtin-config-ix.cmake#L4-L5

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20210311/4bdb5167/attachment.html>

Hi,

On Thu, 11 Mar 2021, Shoaib Meenai via llvm-dev wrote:
> What’s happening is that the configuration for the builtins for Android 
> tests for all supported architectures [1], using check_symbol_exists to 
> check for the architecture’s preprocessor macro [2]. check_symbol_exists 
> tries to link a test executable, which fails because my just-built 
> compiler doesn’t have compiler-rt yet (since it’s trying to build 
> compiler-rt). Consequently, the builtins don’t think that any 
> architectures are supported, and just don’t build anything as a result.
> 
>  
> 
> Other places in the builtins’ CMake logic use custom functions like
> try_compile_only to only test compilation and not linking, to avoid issues
> like this. My understanding is that the builtins will never be built as
> shared libraries. The build already instructs its custom test macros to
> always only check compilation [3]; now that we’re on a newer CMake version,
> would it be appropriate to always set CMAKE_TRY_COMPILE_TARGET_TYPE to
> STATIC_LIBRARY for the builtins as well, so that all CMake checks build
> static libraries (which has the same effect of only testing compilation and
> not linking)? We could also probably clean up a lot of the custom logic for
> only checking compilation afterwards.
These kinds of chicken-and-egg problems are all over building the 
runtimes, and when building the initial copy of runtime libraries, there's 
some amount of trickery needed to pass such tests.

In most of the cases where I build runtimes, I've had to add 
-DCMAKE_C_COMPILER_WORKS=TRUE -DCMAKE_CXX_COMPILER_WORKS=TRUE, but iirc 
one of such cases for compiler-rt could be removed if we'd set 
CMAKE_TRY_COMPILE_TARGET_TYPE to STATIC_LIBRARY. (For 
libunwind/libcxxabi/libcxx, things were more complicated though, I think.)

I actually sent a patch to this effect a couple months ago, have a look at 
[1]. That one was only aimed at standalone builds of 
compiler-rt/lib/builtins, but maybe it could be generalized to some other 
location as well. For non-standalone builds, I guess the option would have 
to be cleared after processing the current project?

// Martin

[1] https://reviews.llvm.org/D91334

Shoaib Meenai wrote:
> https://reviews.llvm.org/D96404 landed recently to default Android
> targets to using compiler-rt instead of libgcc. Amusingly enough, it
> broke our builds of compiler-rt for Android in the runtimes build
> setup. What’s happening is that the configuration for the builtins
> for Android tests for all supported architectures [1], using
> check_symbol_exists to check for the architecture’s preprocessor
> macro [2]. check_symbol_exists tries to link a test executable,
> which fails because my just-built compiler doesn’t have compiler-rt
> yet (since it’s trying to build compiler-rt). Consequently,
> the builtins don’t think that any architectures are supported, and
> just don’t build anything as a result.
Hi all,

I've raised the topic back in November[0], and this what still works
for me (thanks to the suggestions by Martin and Chris):
1. Get the sources.
2. Build clang, llvm, lld.
3. Install libc headers to a sysroot.
4. Build compiler-rt builtins and crt with the freshly-built clang.
One need to set C_COMPILER_WORKS to skip the checks.
5. Build libc.a/libc.so

Then the script builds libc++, libc++abi, libunwind, and it results in a
working C/C++ cross-compiler.  The libc is musl, but I think this works
with any libc.  

compiler-rt C_COMPILER_WORKS checks are unnecessary because it doesn't
need itself (or any runtimes) and libc to be built.


[0]: https://lists.llvm.org/pipermail/llvm-dev/2020-November/146450.html

-- 
caóc