CMake build for compiler-rt should use just-built clang

[llvmbot]

Bugzilla Link	14109
Resolution	FIXED
Resolved on	Oct 27, 2015 14:59
Version	unspecified
OS	All
Blocks	llvm/llvm-bugzilla-archive#15732
Reporter	LLVM Bugzilla Contributor
CC	@llvm-beanz,@eugenis,@ramosian-glider,@kcc,@rnk,@seanm

Extended Description

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.

[llvmbot]

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.

[llvmbot]

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.

[rnk]

What's the status of this today? Do we build compiler-rt with CMAKE_C_COMPILER by default?

[llvmbot]

Yes, today we build compiler-rt with host compiler by default.

[llvmbot]

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)?

[llvmbot]

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.

[llvmbot]

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.

[eugenis]

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

[llvm-beanz]

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.

[llvmbot]

A good first step would be to switch over a couple of the buildbots.

[llvm-beanz]

Marking as resolved. Please report any issues as new bugs.

[sylvestre]

mentioned in issue llvm/llvm-bugzilla-archive#15732