Should buildbots switch to ENABLE_RUNTIMES instead of ENABLE_PROJECTS for compiler-rt?

Runtimes
1

So I’m looking at unpicking arm/armhf library paths and one part of that business is getting our (Linaro’s) bots back on track.

I see from https://compiler-rt.llvm.org/ that -DLLVM_ENABLE_RUNTIMES= is the recommended way to build compiler-rt.

However, looking at zorg’s zorg/buildbot/builders/ClangBuilder.py the majority of bots with compiler-rt are still adding it to LLVM_ENABLE_PROJECTS.

Is that a problem, is ENABLE_RUNTIMES the future, is there a point where ENABLE_PROJECTS will stop working/bit rot over time?

I wonder which configuration we should be validating.

2

LLVM_ENABLE_PROJECTS=libcxx;libcxxabi;libunwind is deprecated and will soon be unsupported (⚙ D132480 [llvm] Remove libcxx, libcxxabi and libunwind from supported LLVM_ENABLE_PROJECTS).

For compiler-rt, perhaps we can say -DLLVM_ENABLE_RUNTIMES=compiler-rt is strongly recommended, though -DLLVM_ENABLE_PROJECTS=compiler-rt works. GCC occasionally imports compiler-rt into their libsanitizer, I think they only need to build it with trunk GCC.

If -DLLVM_ENABLE_PROJECTS=compiler-rt requires workarounds with some older compiler, I think we can say that is unsupported. Personally I prefer -DLLVM_ENABLE_PROJECTS=compiler-rt stays as that makes my compiler-rt development somewhat easy. I haven’t evaluated how much build system we have to retain the support.

For build bots, it may be a good idea to migrate to -DLLVM_ENABLE_RUNTIMES=compiler-rt, to be consistent with libcxx;libcxxabi;libunwind, and to avoid possible gotcha mixing LLVM_ENABLE_RUNTIMES/LLVM_ENABLE_PROJECTS.

2 Likes
3

I think we should deprecate -DLLVM_ENABLE_PROJECTS=compiler-rt altogether and only support -DLLVM_ENABLE_RUNTIMES=compiler-rt. Note that doing so doesn’t mean that you won’t be able to build compiler-rt with another compiler.

There are two different ways to build runtimes:

  • Runtimes build which is used to build one or more runtimes. To do so, you’d use the following:
    cmake -DLLVM_ENABLE_RUNTIMES=<list of runtimes> <other CMake flags> ${LLVM_SRC_DIR}/runtimes
  • Bootstrapping build which is used to build one or more runtimes with the just built Clang toolchain. It invokes runtimes build as a subbuild. You use it as follows:
    cmake -DLLVM_ENABLE_RUNTIMES=<list of runtimes> <other CMake flags> ${LLVM_SRC_DIR}/llvm

For example, to build compiler-rt with GCC in the runtimes build, you’d use:

cmake -DCMAKE_C_COMPILER=gcc -DCMAKE_CXX_COMPILER=g++ -DLLVM_ENABLE_RUNTIMES=compiler-rt <other CMake flags> ${LLVM_SRC_DIR}/runtimes

Today, you can achieve the same with either:

cmake -DCMAKE_C_COMPILER=gcc -DCMAKE_CXX_COMPILER=g++ -DLLVM_ENABLE_PROJECTS=compiler-rt <other CMake flags> ${LLVM_SRC_DIR}/llvm

or:

cmake -DCMAKE_C_COMPILER=gcc -DCMAKE_CXX_COMPILER=g++ <other CMake flags> ${LLVM_SRC_DIR}/compiler-rt

The main advantage of using the runtimes build is that we can avoid the CMake duplication between different runtimes builds and simplify maintenance.

For example, in libcxx, libcxxabi and libunwind, we had similar logic duplicated three times. That’s because someone would write it first in one of the runtimes, and then someone else would copy & paste it into other two, but then others would start making changes and wouldn’t often replicate those changes in every copy, and we would end up with similar but different copies making maintenance a nightmare. With the runtimes build, we can deduplicate all of that logic and have only a single copy that’s shared by all runtimes.

You can already build compiler-rt with -DLLVM_ENABLE_RUNTIMES=compiler-rt, but we can’t start removing a lot of this complexity until we deprecate -DLLVM_ENABLE_PROJECTS=compiler-rt like we did for libcxx, libcxxabi and libunwind. I believe this would be a huge improvement.

For example, compiler-rt build already supports building tests with the just built Clang, but rather than relying on the bootstrapping build, it does so by manually invoking Clang as a custom command which means that a lot of the standard flag handling provided by CMake doesn’t work, and it requires developers to use various workarounds.

Note that we may not be quite ready to deprecate -DLLVM_ENABLE_PROJECTS=compiler-rt yet. Even though -DLLVM_ENABLE_RUNTIMES=compiler-rt has been supported for some time, it’s not widely used—most notably, it’s not used by buildbots—so there might be scenarios that are broken, but it would be great if we can start promoting its use so we find and address all the issues, and aim for deprecation and removal of -DLLVM_ENABLE_PROJECTS=compiler-rt ideally after the LLVM 16 branch point.

Updating all buildbots to use -DLLVM_ENABLE_RUNTIMES=compiler-rt would be a first great step towards the eventual deprecation.

1 Like
4

I was going to say that test-release.sh probably also needs updating, but it seems that already happened :slight_smile: ⚙ D112748 [release] Use the Bootstrapping build for building LLVM releases

I worry that we’re moving to a “the current way is deprecated and the new way isn’t working yet” situation. For example,

$ cmake -GNinja -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_PROJECTS='clang;lld' -DLLVM_ENABLE_RUNTIMES=compiler-rt ../llvm
$ ninja check-asan   
ninja: error: unknown target 'check-asan', did you mean 'check-clang'?


$ cmake -GNinja -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_PROJECTS='clang;lld;compiler-rt' ../llvm
$ ninja check-asan
(runs the tests)
5

Yeah we shipped 14.x with this and now also 15.x has been using this since the start. But I don’t think the Windows batch script has been updated to do this. We should make sure that works before 16.x.

6

Sounds good to me.

I will start this process and will specifically handle Linaro’s bots.

If it’s as simple as moving some cmake options around, I should be able to add an option to zorg to put certain projects in runtimes instead of projects. That can be opt in initially, changing to an opt out as other bot maintainers validate it works for them.

Once I have a change for review I’ll also post here on discourse and include the maintainers of other bots that use compiler-rt.

This is why I asked this question in fact, which gives me hope that the Arm/AArch64 side should be ok if we’ve managed to build releases for them.

7

There is one lingering issue that I know about with the runtime builds - check-all didn’t run all the runtime tests - this was fixed by @petrhosek - but then reverted because of a issue:

:gear: D132438 [runtimes] Use a response file for runtimes test suites (llvm.org)

This should be fixed on main as soon as it’s possible especially if the bots are moving to use this method. If this patch is not landed all the tests are not executed correctly, which is not great.

8

I’ve made a note to give this a try once 15 has shipped.

1 Like
9

Sounds good. I think deprecating -DLLVM_ENABLE_PROJECTS=compiler-rt is fine (we need help from build bot maintainers to migrate their use cases and ensure LLVM_ENABLE_RUNTIMES=compiler-rt works for them).

10

I gave this a go and quickly ran into problems (`check-compiler-rt` fails with various errors when using the runtimes build on windows · Issue #58568 · llvm/llvm-project · GitHub for a start) which seems consistent with the “the working way is deprecated, and the new way isn’t ready yet” situation (s/Google/llvm/ here).

Happy to give it another try in the future if the support improves.

11

Thanks for the info, I have also been watching ⚙ D132438 [runtimes] Use a response file for runtimes test suites. Until the issues are ironed out there our (Linaro’s) bots will continue using PROJECTS.

12

All Linaro’s bots are now building compiler-rt as a runtime and have had no issues with it so far.

I will be contacting other bot owners over the coming days to see if they would like to do the same. If not or I am unable to find a contact, I will update their config to explicitly disable the use of runtimes. Then finally the default(s) can be flipped.

1 Like
13

Hi @petrhosek ,

Thanks for the confirmation.

Well I am testing compiler-rt in LLVM_ENABLE_RUNTIMES with parallel build setup of using multiple kernel threads enabled (i.e 4,16,32,64,112(max hyperthreading in my system)).

This happens occasionally for the runtimes build configuration invoked from the llvm/runtimes/CMakeLists.txt. Do you have any idea how to resolve it.

CMake Configuration Command for LLVM Project
cmake ‘-DCMAKE_PREFIX_PATH=/home/ampandey/rocm-toolchain/rocm-5.6/llvm;/home/ampandey/rocm-toolchain/rocm-5.6’ -DCMAKE_BUILD_TYPE=Release -DCMAKE_VERBOSE_MAKEFILE=1 -DCPACK_GENERATOR=DEB ‘-DCMAKE_INSTALL_RPATH=$ORIGIN:$ORIGIN/…/lib:$ORIGIN/…/lib64:/opt/rocm-5.6.0-9999/lib:/opt/rocm-5.6.0-9999/lib64:/opt/rocm/lib:/opt/rocm/lib64:$ORIGIN/…/llvm/lib’ -DCMAKE_INSTALL_RPATH_USE_LINK_PATH=FALSE -DROCM_PATCH_VERSION=50600 -DCMAKE_INSTALL_PREFIX=/home/ampandey/rocm-toolchain/rocm-5.6 -DCPACK_PACKAGING_INSTALL_PREFIX=/home/ampandey/rocm-toolchain/rocm-5.6 -DCMAKE_INSTALL_PREFIX=/home/ampandey/rocm-toolchain/rocm-5.6/llvm ‘-DLLVM_TARGETS_TO_BUILD=AMDGPU;X86’ ‘-DLLVM_ENABLE_PROJECTS=clang;lld;clang-tools-extra’ ‘-DLLVM_ENABLE_RUNTIMES=libcxx;libcxxabi;compiler-rt’ -DLIBCXX_ENABLE_SHARED=OFF -DLIBCXX_ENABLE_STATIC=ON -DLIBCXX_INSTALL_LIBRARY=OFF -DLIBCXX_INSTALL_HEADERS=OFF -DLIBCXXABI_ENABLE_SHARED=OFF -DLIBCXXABI_ENABLE_STATIC=ON -DLIBCXXABI_INSTALL_STATIC_LIBRARY=OFF -DLLVM_BUILD_DOCS=OFF -DLLVM_ENABLE_SPHINX=OFF -DSPHINX_WARNINGS_AS_ERRORS=OFF -DSPHINX_OUTPUT_MAN=OFF -DLLVM_ENABLE_ASSERTIONS=1 -DLLVM_ENABLE_Z3_SOLVER=OFF -DLLVM_ENABLE_ZLIB=ON -DLLVM_AMDGPU_ALLOW_NPI_TARGETS=ON -DCLANG_DEFAULT_PIE_ON_LINUX=0 -DCLANG_DEFAULT_LINKER=lld -DCLANG_DEFAULT_RTLIB=compiler-rt -DCLANG_DEFAULT_UNWINDLIB=libgcc -DPACKAGE_VENDOR=AMD -DLLVM_BUILD_LLVM_DYLIB=OFF -DLLVM_LINK_LLVM_DYLIB=OFF -DLLVM_ENABLE_LIBCXX=OFF /home/ampandey/rocm-toolchain/build/…/external/llvm-project/llvm

I am seeing following failures:-

[ 96%] Performing configure step for 'runtimes'
cd /home/ampandey/rocm-toolchain/out/ubuntu-20.04/20.04/build/lightning/runtimes/runtimes-bins && /usr/local/bin/cmake --no-warn-unused-cli -DCMAKE_C_COMPILER=/home/ampandey/rocm-toolchain/out/ubuntu-20.04/20.04/build/lightning/./bin/clang -DCMAKE_CXX_COMPILER=/home/ampa
ndey/rocm-toolchain/out/ubuntu-20.04/20.04/build/lightning/./bin/clang++ -DCMAKE_ASM_COMPILER=/home/ampandey/rocm-toolchain/out/ubuntu-20.04/20.04/build/lightning/./bin/clang -DCMAKE_LINKER=/home/ampandey/rocm-toolchain/out/ubuntu-20.04/20.04/build/lightning/./bin/ld.lld
 -DCMAKE_AR=/home/ampandey/rocm-toolchain/out/ubuntu-20.04/20.04/build/lightning/./bin/llvm-ar -DCMAKE_RANLIB=/home/ampandey/rocm-toolchain/out/ubuntu-20.04/20.04/build/lightning/./bin/llvm-ranlib -DCMAKE_NM=/home/ampandey/rocm-toolchain/out/ubuntu-20.04/20.04/build/ligh
tning/./bin/llvm-nm -DCMAKE_OBJDUMP=/home/ampandey/rocm-toolchain/out/ubuntu-20.04/20.04/build/lightning/./bin/llvm-objdump -DCMAKE_OBJCOPY=/home/ampandey/rocm-toolchain/out/ubuntu-20.04/20.04/build/lightning/./bin/llvm-objcopy -DCMAKE_STRIP=/home/ampandey/rocm-toolchain
/out/ubuntu-20.04/20.04/build/lightning/./bin/llvm-strip -DCMAKE_READELF=/home/ampandey/rocm-toolchain/out/ubuntu-20.04/20.04/build/lightning/./bin/llvm-readelf -DCMAKE_C_COMPILER_TARGET=x86_64-unknown-linux-gnu -DCMAKE_CXX_COMPILER_TARGET=x86_64-unknown-linux-gnu -DCMAK
E_ASM_COMPILER_TARGET=x86_64-unknown-linux-gnu -DCMAKE_INSTALL_PREFIX=/home/ampandey/rocm-toolchain/rocm-5.6/llvm -DLLVM_BINARY_DIR=/home/ampandey/rocm-toolchain/out/ubuntu-20.04/20.04/build/lightning -DLLVM_CONFIG_PATH=/home/ampandey/rocm-toolchain/out/ubuntu-20.04/20.0
4/build/lightning/bin/llvm-config -DLLVM_ENABLE_WERROR=OFF -DLLVM_HOST_TRIPLE=x86_64-unknown-linux-gnu -DLLVM_HAVE_LINK_VERSION_SCRIPT=1 -DLLVM_USE_RELATIVE_PATHS_IN_DEBUG_INFO=OFF -DLLVM_USE_RELATIVE_PATHS_IN_FILES=OFF -DLLVM_LIT_ARGS=-sv -DLLVM_SOURCE_PREFIX= -DPACKAGE
_VERSION=17.0.0git -DCMAKE_BUILD_TYPE=Release -DCMAKE_MAKE_PROGRAM=/bin/make -DCMAKE_C_COMPILER_LAUNCHER= -DCMAKE_CXX_COMPILER_LAUNCHER= -DCMAKE_EXPORT_COMPILE_COMMANDS=1 -DCOMPILER_RT_BUILD_BUILTINS=Off -DLLVM_INCLUDE_TESTS=ON -DLLVM_DEFAULT_TARGET_TRIPLE=x86_64-unknown
-linux-gnu -DLLVM_ENABLE_PROJECTS_USED=ON -DLLVM_ENABLE_PER_TARGET_RUNTIME_DIR=OFF -DLLVM_BUILD_TOOLS=ON -DCMAKE_C_COMPILER_WORKS=ON -DCMAKE_CXX_COMPILER_WORKS=ON -DCMAKE_ASM_COMPILER_WORKS=ON -DHAVE_LLVM_LIT=ON "-DLLVM_ENABLE_RUNTIMES=libcxx;libcxxabi;compiler-rt" -DLIB
CXXABI_ENABLE_SHARED=OFF -DLIBCXXABI_ENABLE_STATIC=ON -DLIBCXXABI_INSTALL_STATIC_LIBRARY=OFF -DLIBCXX_ENABLE_SHARED=OFF -DLIBCXX_ENABLE_STATIC=ON -DLIBCXX_INSTALL_HEADERS=OFF -DLIBCXX_INSTALL_LIBRARY=OFF -DLIBCXXABI_ENABLE_SHARED=OFF -DLIBCXXABI_ENABLE_STATIC=ON -DLIBCXX
ABI_INSTALL_STATIC_LIBRARY=OFF "-GUnix Makefiles" /home/ampandey/rocm-toolchain/external/llvm-project/llvm/runtimes/../../runtimes
Not searching for unused variables given on the command line.
Re-run cmake no build system arguments
-- The C compiler identification is Clang 17.0.0
-- The CXX compiler identification is Clang 17.0.0
-- The ASM compiler identification is Clang with GNU-like command-line
-- Found assembler: /home/ampandey/rocm-toolchain/out/ubuntu-20.04/20.04/build/lightning/./bin/clang
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /home/ampandey/rocm-toolchain/out/ubuntu-20.04/20.04/build/lightning/./bin/clang - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /home/ampandey/rocm-toolchain/out/ubuntu-20.04/20.04/build/lightning/./bin/clang++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Performing Test Terminfo_LINKABLE
-- Performing Test Terminfo_LINKABLE - Success
-- Found Terminfo: /usr/lib/x86_64-linux-gnu/libtinfo.so
-- Found ZLIB: /usr/lib/x86_64-linux-gnu/libz.so (found version "1.2.11")
-- Performing Test LLVM_RUNTIMES_LINKING_WORKS
/bin/make  -f runtimes/CMakeFiles/runtimes.dir/build.make runtimes/CMakeFiles/runtimes.dir/depend
make[2]: Entering directory '/work/ampandey/rocm-toolchain/out/ubuntu-20.04/20.04/build/lightning'
cd /home/ampandey/rocm-toolchain/out/ubuntu-20.04/20.04/build/lightning && /usr/local/bin/cmake -E cmake_depends "Unix Makefiles" /home/ampandey/rocm-toolchain/external/llvm-project/llvm /home/ampandey/rocm-toolchain/external/llvm-project/llvm/runtimes /home/ampandey/roc
m-toolchain/out/ubuntu-20.04/20.04/build/lightning /home/ampandey/rocm-toolchain/out/ubuntu-20.04/20.04/build/lightning/runtimes /home/ampandey/rocm-toolchain/out/ubuntu-20.04/20.04/build/lightning/runtimes/CMakeFiles/runtimes.dir/DependInfo.cmake --color=
make[2]: Leaving directory '/work/ampandey/rocm-toolchain/out/ubuntu-20.04/20.04/build/lightning'
/bin/make  -f runtimes/CMakeFiles/runtimes.dir/build.make runtimes/CMakeFiles/runtimes.dir/build
make[2]: Entering directory '/work/ampandey/rocm-toolchain/out/ubuntu-20.04/20.04/build/lightning'
[ 96%] Performing configure step for 'runtimes'
cd /home/ampandey/rocm-toolchain/out/ubuntu-20.04/20.04/build/lightning/runtimes/runtimes-bins && /usr/local/bin/cmake --no-warn-unused-cli -DCMAKE_C_COMPILER=/home/ampandey/rocm-toolchain/out/ubuntu-20.04/20.04/build/lightning/./bin/clang -DCMAKE_CXX_COMPILER=/home/ampa
ndey/rocm-toolchain/out/ubuntu-20.04/20.04/build/lightning/./bin/clang++ -DCMAKE_ASM_COMPILER=/home/ampandey/rocm-toolchain/out/ubuntu-20.04/20.04/build/lightning/./bin/clang -DCMAKE_LINKER=/home/ampandey/rocm-toolchain/out/ubuntu-20.04/20.04/build/lightning/./bin/ld.lld
 -DCMAKE_AR=/home/ampandey/rocm-toolchain/out/ubuntu-20.04/20.04/build/lightning/./bin/llvm-ar -DCMAKE_RANLIB=/home/ampandey/rocm-toolchain/out/ubuntu-20.04/20.04/build/lightning/./bin/llvm-ranlib -DCMAKE_NM=/home/ampandey/rocm-toolchain/out/ubuntu-20.04/20.04/build/ligh
tning/./bin/llvm-nm -DCMAKE_OBJDUMP=/home/ampandey/rocm-toolchain/out/ubuntu-20.04/20.04/build/lightning/./bin/llvm-objdump -DCMAKE_OBJCOPY=/home/ampandey/rocm-toolchain/out/ubuntu-20.04/20.04/build/lightning/./bin/llvm-objcopy -DCMAKE_STRIP=/home/ampandey/rocm-toolchain
/out/ubuntu-20.04/20.04/build/lightning/./bin/llvm-strip -DCMAKE_READELF=/home/ampandey/rocm-toolchain/out/ubuntu-20.04/20.04/build/lightning/./bin/llvm-readelf -DCMAKE_C_COMPILER_TARGET=x86_64-unknown-linux-gnu -DCMAKE_CXX_COMPILER_TARGET=x86_64-unknown-linux-gnu -DCMAK
E_ASM_COMPILER_TARGET=x86_64-unknown-linux-gnu -DCMAKE_INSTALL_PREFIX=/home/ampandey/rocm-toolchain/rocm-5.6/llvm -DLLVM_BINARY_DIR=/home/ampandey/rocm-toolchain/out/ubuntu-20.04/20.04/build/lightning -DLLVM_CONFIG_PATH=/home/ampandey/rocm-toolchain/out/ubuntu-20.04/20.0
4/build/lightning/bin/llvm-config -DLLVM_ENABLE_WERROR=OFF -DLLVM_HOST_TRIPLE=x86_64-unknown-linux-gnu -DLLVM_HAVE_LINK_VERSION_SCRIPT=1 -DLLVM_USE_RELATIVE_PATHS_IN_DEBUG_INFO=OFF -DLLVM_USE_RELATIVE_PATHS_IN_FILES=OFF -DLLVM_LIT_ARGS=-sv -DLLVM_SOURCE_PREFIX= -DPACKAGE
_VERSION=17.0.0git -DCMAKE_BUILD_TYPE=Release -DCMAKE_MAKE_PROGRAM=/bin/make -DCMAKE_C_COMPILER_LAUNCHER= -DCMAKE_CXX_COMPILER_LAUNCHER= -DCMAKE_EXPORT_COMPILE_COMMANDS=1 -DCOMPILER_RT_BUILD_BUILTINS=Off -DLLVM_INCLUDE_TESTS=ON -DLLVM_DEFAULT_TARGET_TRIPLE=x86_64-unknown
-linux-gnu -DLLVM_ENABLE_PROJECTS_USED=ON -DLLVM_ENABLE_PER_TARGET_RUNTIME_DIR=OFF -DLLVM_BUILD_TOOLS=ON -DCMAKE_C_COMPILER_WORKS=ON -DCMAKE_CXX_COMPILER_WORKS=ON -DCMAKE_ASM_COMPILER_WORKS=ON -DHAVE_LLVM_LIT=ON "-DLLVM_ENABLE_RUNTIMES=libcxx;libcxxabi;compiler-rt" -DLIB
CXXABI_ENABLE_SHARED=OFF -DLIBCXXABI_ENABLE_STATIC=ON -DLIBCXXABI_INSTALL_STATIC_LIBRARY=OFF -DLIBCXX_ENABLE_SHARED=OFF -DLIBCXX_ENABLE_STATIC=ON -DLIBCXX_INSTALL_HEADERS=OFF -DLIBCXX_INSTALL_LIBRARY=OFF -DLIBCXXABI_ENABLE_SHARED=OFF -DLIBCXXABI_ENABLE_STATIC=ON -DLIBCXX
ABI_INSTALL_STATIC_LIBRARY=OFF "-GUnix Makefiles" /home/ampandey/rocm-toolchain/external/llvm-project/llvm/runtimes/../../runtimes
Not searching for unused variables given on the command line.
Re-run cmake no build system arguments
-- Performing Test LLVM_RUNTIMES_LINKING_WORKS - Failed
-- Performing Test CXX_SUPPORTS_UNWINDLIB_EQ_NONE_FLAG
CMake Error: CMAKE_C_COMPILER not set, after EnableLanguage
CMake Error at /usr/local/share/cmake-3.25/Modules/Internal/CheckSourceCompiles.cmake:101 (try_compile):
  Failed to configure test project build system.
Call Stack (most recent call first):
  /usr/local/share/cmake-3.25/Modules/Internal/CheckCompilerFlag.cmake:18 (cmake_check_source_compiles)
  /usr/local/share/cmake-3.25/Modules/CheckCompilerFlag.cmake:40 (cmake_check_compiler_flag)
  /home/ampandey/rocm-toolchain/external/llvm-project/cmake/Modules/LLVMCheckCompilerLinkerFlag.cmake:22 (check_compiler_flag)
  CMakeLists.txt:113 (llvm_check_compiler_linker_flag)

-- Configuring incomplete, errors occurred!
See also "/home/ampandey/rocm-toolchain/out/ubuntu-20.04/20.04/build/lightning/runtimes/runtimes-bins/CMakeFiles/CMakeOutput.log".
See also "/home/ampandey/rocm-toolchain/out/ubuntu-20.04/20.04/build/lightning/runtimes/runtimes-bins/CMakeFiles/CMakeError.log".
make[2]: *** [runtimes/CMakeFiles/runtimes-configure.dir/build.make:78: runtimes/runtimes-stamps/runtimes-configure] Error 1
make[2]: Leaving directory '/work/ampandey/rocm-toolchain/out/ubuntu-20.04/20.04/build/lightning'
make[1]: *** [CMakeFiles/Makefile2:107076: runtimes/CMakeFiles/runtimes-configure.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....

Thanks & Regards
Amit
CMakeError.log.txt (100.6 KB)
CMakeOutput.log.txt (504.3 KB)

14

Can you open an issue Issues · llvm/llvm-project · GitHub describing exactly what you’re doing? It’ll keep this, and that discussion, on topic.

15

Hi DavidSpickett,

Please ignore the above error as I have switched the default build to NINJA.

I have posted the new issue on llvm-project issues as it somewhat related to this work of moving compiler-rt to LLVM_ENABLE_RUNTIMES in our internal CI’s.

Can you please respond to that thanks.

16

I just landed ⚙ D148503 [ClangBuilder] Change default of enable_runtimes to "auto" which flips the default setting so that the majority of the Clang builders are now using LLVM_ENABLE_RUNTIMES for compiler-rt, and new bots will do so too.

Builders that can’t use the runtimes build (reasons are recorded in my commits to llvm-zorg) now pass enable_runtimes=None to opt out.

There are some other builder types that likely aren’t using the runtimes build, but I don’t know the use cases very well so I am going to leave those alone.

2 Likes