This would be useful as: 1) We'd be able to compile compiler-rt libraries for many targets (that is, for targets supported by clang). 2) We'd need to support a single compiler (ToT Clang) instead of all kinds of host compilers users may have. 3) It may simplify building ASan/(MSan?) unit tests that require instrumentation, as just-built clang would have the "-faddress-sanitizer" flag working.
Update (from Sanitizer tools perspective): 1) We still build compiler-rt libraries for targets that are supported by host compiler (e.g. on x86_64 and Linux we usually build compiler-rt libs for x86_64 and i386). 2) We maintain both clang and gcc builds of LLVM/Clang/compiler-rt trees, and use -Werror for the Clang build. 3) ASan/MSan unit tests are now compiled and linked with just-built Clang, and we're able to build both 64-bit and 32-bit tests in a single build tree.
FWIW, I still like having a choice in compiler for building compiler-rt. I currently build the powerpc-darwin8 branch using g++-4.0 in stage-1, and only recently have been able to build stage-2 compiler-rt using stage-1-clang. Besides, in the current state, it is fairly easy to build compiler-rt using clang in a second stage.
What's the status of this today? Do we build compiler-rt with CMAKE_C_COMPILER by default?
Yes, today we build compiler-rt with host compiler by default.
I started to look at implementing this, and discovered that Alexey has already written & committed a patch to do it: https://www.mail-archive.com/cfe-commits@cs.uiuc.edu/msg91501.html What would it take to get LLVM_BUILD_EXTERNAL_COMPILER_RT turned on by default (so as to unblock bug 15732)?
(In reply to comment #5) > I started to look at implementing this, and discovered that Alexey has > already written & committed a patch to do it: > https://www.mail-archive.com/cfe-commits@cs.uiuc.edu/msg91501.html > > What would it take to get LLVM_BUILD_EXTERNAL_COMPILER_RT turned on by > default (so as to unblock bug 15732)? I did just try to turn it ON an got that error while configuring the project: CMake Error at tools/clang/runtime/CMakeLists.txt:28 (message): Ninja generator can't build compiler-rt as ExternalProject.Unset LLVM_BUILD_EXTERNAL_COMPILER_RT, or don't use Ninja.See http://www.cmake.org/Bug/view.php?id=14771 So, I don't think turning it ON by default is a good option, at least until we require a cmake version that solve that issue.
Copying my response in llvmdev here: I believe we should revisit this mode and eventually make LLVM_BUILD_EXTERNAL_COMPILER_RT the only available option (for now it's not the default and only runs on our buildbot). I'll see if we can workaround the Ninja problem somehow. I also believe we should do a major rewrite of the way this mode (and CMake build for compiler-rt) is implemented. Instead of having a single compiler-rt build tree that would guess which architectures the host compiler can target, and build runtimes for all of them (which leads to "foreach(arch ${SANITIZER_COMMON_SUPPORTED_ARCH})" all around), we might instead create one build tree for each target we support, and pass host compiler (just-built Clang) and flags to target that architecture (we may cross-compile) down to that build tree. That would drastically simplify CMake build rules. I hope I will be able to experiment with that soon.
Note that Android build of compiler-rt (see if (ANDROID) branches in CMake) is already factored the way you describe, and it is indeed very simple
This should work now as of r250064. It is not enabled by default, but setting `-DLLVM_BUILD_EXTERNAL_COMPILER_RT=On` on the CMake command line should make this work. We should consider making this the default behavior once this has been tested a bit more widely.
A good first step would be to switch over a couple of the buildbots.
Marking as resolved. Please report any issues as new bugs.