Problem on cross-compiling compiler-rt

I’m trying to use Clang/LLVM as a cross-compiling toolchain. In previous version of LLVM with the old configure/Makefile building system, I’m able to build Clang/LLVM for target architecture with the host GCC firstly and then use the generated cross compiler to compile the compiler-rt project, and, consequently, I can get a cross compiler as well as the compiler-rt library. However, when I move to version 3.9 which abandoned configure/Makefile and uses CMake now, it always compile the compiler-rt simultaneously with the host GCC. The same problem is also existing in 3.5 CMake building system. It seems that in the CMake building system compiler-rt is not dependent on the generated toolchain. I also tried to compile the compiler-rt after Clang/LLVM has been built, and there is another problem that the generated Clang/LLVM cannot pass the CMake checking without compiler-rt, which is obvious… So is there any way that I can solve this problem. Thank you.

Lei Wang

Hi WangLei,

Do you mean that the version 3.9 is LLVM project 3.9 and 3.5 is CMake 3.5?

In the guide[GetStarted.rst], the tutorial says before running CMake command, you must checkout all the source code. CMake does not pickup newly added source directories in incremental builds.

Have you cross-compiled the LLVM/Clang for ARM, or other successfully?


This is currently a rough area in our build system, but there are two CMake options you probably need to set.

(1) -DLLVM_BUILD_EXTERNAL_COMPILER_RT=On —> This option causes the build to use the just-built clang when building compiler-rt
(2) -DCOMPILER_RT_DEFAULT_TARGET_ARCH=??? —> This is where you specify which architecture you want to build the compiler-rt archives and libraries for

Hopefully in the near future we’ll have a better story for building this functionality.

Hope this helps,

I finally solved my problem. Chris’s suggestion helps much, but there are still a few problems to build cross platform compiler-rt.
-DLLVM_BUILD_EXTERNAL_COMPILER_RT=On → This is valid and required to force compiler-rt to be built by the just-built clang.
While using there two additional options, I still got errors. The build system successfully configured and built clang/LLVM but failed to configure compiler-rt due to the clang checking in compiler-rt’s Cmake system.
I add x86 into LLVM_TARGET_ARCH, and this helps the just-built clang pass the CMake check, but failed in another checking which is invoked by test_target_arch. The test_target_arch is used to setup flags used for building compiler-rt, but it uses try_compile() function, which compiles a simple test code using libraries and invokes linker and linker scripts, flags, etc… Without compiler-rt, clang will, of course, fails to link programs. However, compiler-rt does not need clang to link. I forced try_compile() successful, and everything goes smoothly. Inconveniently, I have to use clang integrated an spare x86 target.
Moreover, in compiler-rt’s built-in library, there are some emulating (?) libraries, such as emutls and eprintf, that are using host system header files, which may potentially cause compatible problem. I’m not sure if they should be included in GENERIC_SOURCES.
I hope this information could help the cross-compiling of compiler-rt.
Thank you. Thanks, Chris and yanglee.



The issues that you’re reporting here are on my mind.

I have a patch out for review now ( that allows building builtins without a full toolchain.

One of the next steps after this is to support alternate sysroots for different targets, and to identify builtins that need target headers so that they can be excluded in cases where target headers are not available. We can drive that all with compiler tests so that it is seamless to the user.

We will also be working on ways of specifying lists of targets to the LLVM/Clang build so that you won’t need to set COMPILER_RT_DEFAULT_TARGET_ARCH, and so that you can easily build for multiple targets while you build clang.


Nice! Does that also allow you to build multiple targets?

No. The plan is to have compiler-rt support one target per-configuration and to have LLVM & Clang’s build systems manage configuring compiler-rt for each target.

I’m still working out the exact details of what that will look like, but I’m expecting to have CMake take a list of targets probably specified by triple.


Sounds great, thanks for that work! And let me know when you have
something, I'd like to test it locally.


That's great. For multi targets compilerrt-rts, in old llvm 3.5 configuremakefileconfigure/makefile system, it will build multiple libs for each target on the target list pass to clang building. but since you said compiler-rt now require sysroot for proper headers, then I don't think multi libs can be built together any more. However, according to my knowledge, without compiler-rt, a compiler is not able to full functionally work, if assuming it is the only compiler runtime lib we have. Clang is designed and able to be built for multi targets, so it should work with different compiler rt libs when it is built for multi targets. So from this viewpoint, multi target lib build is essential to support the multi target clang.
I still do not understanding why including libs using system headers in buildin libs. And what does exactly compiler rt want to replace? In my opinion, it is libgcc?

Lei Wang

I found another bug when compiling external compiler-rt. When configuring LLVM with option -DLLVM_LIBDIR_SUFFIX=64, this option is not pass to compiler-rt which causes LLVM cmake modules cannot be found. Without -DLLVM_LIBDIR_SUFFIX=64 may cause other failures (lldb installation on 64-bit linux).


I’ve committed a fix for this issue in r269069.