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

Shoaib Meenai via llvm-dev llvm-dev at lists.llvm.org
Wed Mar 10 22:55:30 PST 2021


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>


More information about the llvm-dev mailing list