[compiler-rt] Don't require c++ headers when configuring compiler-rt builds

[fjricci]

Summary

A sysroot without c++ headers is able to build compiler-rt, don't
require them when configuring available architectures from cmake.

[compnerd]

cmake/config-ix.cmake

96

Please include a symbol that requires linkage. How about printf?

[fjricci]

Add 'printf' call to simple source file

[fjricci]

Fix syntax error

[compnerd]

LGTM, would be nice to have @beanz sign off on it as well.

[beanz]

Sorry for being late to this change. I was on vacation last week.

My only concern about this is that compiler-rt's tests do use C++, but that probably isn't a big enough deal to matter. We can deal with that if it ever comes up.

[Hahnfeld]

In D22469#495057, @beanz wrote:

Sorry for being late to this change. I was on vacation last week.

My only concern about this is that compiler-rt's tests do use C++, but that probably isn't a big enough deal to matter. We can deal with that if it ever comes up.

Actually the sanitizers are using C++ while builtins only rely on C. I'm currently running into this because I'm only building libc++ for 64 bits and it tries to build sanitizers for 32 bit which obviously does not work

[beanz]

@Hahnfeld, I thought that while the sanitizers are written in C++ they don't actually use libcxx.

-Chris

[Hahnfeld]

In D22469#500819, @beanz wrote:

@Hahnfeld, I thought that while the sanitizers are written in C++ they don't actually use libcxx.

-Chris

They may not, I don't know. But clang tries to link because no -nostdlib is provided

[Hahnfeld]

In D22469#500936, @Hahnfeld wrote:

In D22469#500819, @beanz wrote:

@Hahnfeld, I thought that while the sanitizers are written in C++ they don't actually use libcxx.

-Chris

They may not, I don't know. But clang tries to link because no -nostdlib is provided

The solution seems to be that simple: I posted D23005 which solves the problem for me.

Back to this revision: I think we should check that we actually have a C++ compiler (maybe without C++ headers and library), but not only a C compiler. Otherwise I think the sanitizers will definitely not build...

[beanz]

@Hahnfeld, agreed with one caveat. We should actually have two versions of the test. In config-ix.cmake we should have the source be a C++ file that does not rely on libcxx headers, and in builtin-config-ix.cmake, we should have the source be C only, because the builtin libraries do not use C++ at all.

[Hahnfeld]

In D22469#502308, @beanz wrote:

@Hahnfeld, agreed with one caveat. We should actually have two versions of the test. In config-ix.cmake we should have the source be a C++ file that does not rely on libcxx headers, and in builtin-config-ix.cmake, we should have the source be C only, because the builtin libraries do not use C++ at all.

Yep, and it looks like this is already implemented: builtin-config-ix.cmake sets TEST_COMPILE_ONLY and therefore only calls try_compile_only which produces its own SIMPLE_C.

That said, config-ix.cmake is only included from the top directory and not from lib/builtins (only base-config-ix.cmake and builtin-config-ix.cmake are).
So we should just rename back SIMPLE_SOURCE to simple.cc which makes it compile with a C++ compiler. @fjricci is that acceptable for you?

[compnerd]

I don't think that would work for all cross-compilation scenarios. Using C++ introduces a dependency on libunwind for ARM targets unless we pass in -fno-exceptions and -fno-unwind-tables to the compilation test.

[Hahnfeld]

In D22469#505842, @compnerd wrote:

I don't think that would work for all cross-compilation scenarios. Using C++ introduces a dependency on libunwind for ARM targets unless we pass in -fno-exceptions and -fno-unwind-tables to the compilation test.

Hmm, so you also don't build the sanitizers?

[beanz]

@compnerd,

If you're doing a cross-compile bootstrap you need to build the builtins using lib/builtins as the top-level source directory in order to skip the sanitizer configuration completely. If you're configuring the sanitizers we need the tests to use C++.

-Chris

[compnerd]

@beanz but we do have a bunch of C++ tests that fail miserably due to the libunwind being needed.

[beanz]

@compnerd, which tests? I suspect that is a different problem. Several of the sanitizers require libunwind in order to build. If you're seeing test failures it likely means that the tests requiring libunwind aren't properly gated.

[Hahnfeld]

@compnerd I'm by now a bit lost: How do you compile the sanitizers without a working C++ compiler? They really do need the headers and a linkable library (I tried to add -nostdlib in D23005 but the bots didn't like it)

Or do you pass COMPILER_RT_BUILD_SANITIZERS=Off? I think this will currently not disable the sanitizer tests, maybe this needs to be fixed?
Anyway, could you try directly configuring lib/builtins as Chris suggested? This will only test for a C compiler as I pointed out above.

cmake/config-ix.cmake

 
 # List of all architectures we can target.
 set(COMPILER_RT_SUPPORTED_ARCH)
 
 # Try to compile a very simple source file to ensure we can target the given
 # platform. We use the results of these tests to build only the various target
 # runtime libraries supported by our current compilers cross-compiling
 # abilities.
-set(SIMPLE_SOURCE ${CMAKE_BINARY_DIR}${CMAKE_FILES_DIRECTORY}/simple.cc)
-file(WRITE ${SIMPLE_SOURCE} "#include <stdlib.h>\n#include <limits>\nint main() {}\n")
+set(SIMPLE_SOURCE ${CMAKE_BINARY_DIR}${CMAKE_FILES_DIRECTORY}/simple.c)
+file(WRITE ${SIMPLE_SOURCE} "#include <stdlib.h>\n#include <stdio.h>\nint main(printf(\"hello, world\n\") {}\n")
 
 # Add $arch as supported with no additional flags.
 macro(add_default_target_arch arch)
   set(TARGET_${arch}_CFLAGS "")
   set(CAN_TARGET_${arch} 1)
   list(APPEND COMPILER_RT_SUPPORTED_ARCH ${arch})
 endmacro()