[CMake] Use a different source depending on C++ support

[phosek]

Summary

When using system C++ library, assume we have a working C++ compiler and
try to compile a complete C++ program. When using in tree C++ library,
only check the C compiler since the C++ library likely won't have been
built yet at time of running the check.

[Hahnfeld]

This breaks the build if you are not building a 32bit C++ library, that's why I introduced a check for a full C++ program in D23654. I therefore request this change to be reverted, we need to come up with a better solution that correctly works for in-tree builds.

[Hahnfeld]

In D47169#1118618, @Hahnfeld wrote:

This breaks the build if you are not building a 32bit C++ library, that's why I introduced a check for a full C++ program in D23654. I therefore request this change to be reverted, we need to come up with a better solution that correctly works for in-tree builds.

Ping, this change is not correct!

[Hahnfeld]

Due to the lack of replies, I've reverted this change in rL334903 to unbreak my build. Feel free to submit a patch that doesn't regress the build system, thanks.

[phosek]

In D47169#1134764, @Hahnfeld wrote:

Due to the lack of replies, I've reverted this change in rL334903 to unbreak my build. Feel free to submit a patch that doesn't regress the build system, thanks.

I never got any email, sorry about the lack of the response, I just noticed this because your revert broke our build. What is your build configuration where you're seeing the failure? I'd like to replicate the issue and try to come up with a better solution because now this is blocking us.

[Hahnfeld]

In D47169#1141759, @phosek wrote:

I never got any email, sorry about the lack of the response, I just noticed this because your revert broke our build.

The messages seem to be on llvm-commits (http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20180528/557038.html and http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20180611/thread.html#559742), but in any case you should have received a direct notification from Phabricator. Maybe you might want to check your filters?

What is your build configuration where you're seeing the failure? I'd like to replicate the issue and try to come up with a better solution because now this is blocking us.

I'm on x86_64 but don't have a 32bit version of the C++ libraries (we are bootstrapping Clang with libc++ and -DCLANG_DEFAULT_CXX_STDLIB=libc++). I think this configuration will become more important soon as distributions try to shave support for 32bit libraries and binaries.

The only "correct" solution that I can currently think of is fixing the dependency in runtimes/ (which I assume you are using for Fuchsia):

1. Configure and compile builtins
2. Configure and compile libunwind, libc++abi, and libc++
3. Configure all other runtime libraries, including the sanitizers.

The other approach would be to kill the dependency of the sanitizers to the C++ library - I thought somebody wanted to tackle this in the past, but I'd need to look through the mailing lists.

[phosek]

In D47169#1141824, @Hahnfeld wrote:

The messages seem to be on llvm-commits (http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20180528/557038.html and http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20180611/thread.html#559742), but in any case you should have received a direct notification from Phabricator. Maybe you might want to check your filters?

Seems like a Gmail issue, I've already archived the original thread after submitting the change and Gmail didn't move it back to Inbox after receiving your response which is why I missed it.

I'm on x86_64 but don't have a 32bit version of the C++ libraries (we are bootstrapping Clang with libc++ and -DCLANG_DEFAULT_CXX_STDLIB=libc++). I think this configuration will become more important soon as distributions try to shave support for 32bit libraries and binaries.

We use -DCLANG_DEFAULT_CXX_STDLIB=libc++ in Fuchsia but we also use -DCLANG_DEFAULT_RTLIB=compiler-rt, removing the latter option replicates the issue.

The only "correct" solution that I can currently think of is fixing the dependency in runtimes/ (which I assume you are using for Fuchsia):

1. Configure and compile builtins
2. Configure and compile libunwind, libc++abi, and libc++
3. Configure all other runtime libraries, including the sanitizers.

I came to the same the same conclusion, but I'm not particularly excited about that idea primarily because it'll mean having another CMake invocation making the build even slower.

The other approach would be to kill the dependency of the sanitizers to the C++ library - I thought somebody wanted to tackle this in the past, but I'd need to look through the mailing lists.

I think that's unlikely at this point, libFuzzer and XRay both depend on C++ library and someone would need to rewrite them. Furthermore, many other sanitizers depend on C++ ABI.

There's another solution that's simpler than the two mentioned above which would be to simply avoid using the compiler-rt logic for determining the set of supported targets and instead rely on CMake which is already what runtimes/ build does except for the host (it's the COMPILER_RT_DEFAULT_TARGET_ONLY option). I know which targets I want to build runtimes for, I don't want CMake to go on and try guessing which targets my compiler may or may not support. This needs D45604 but that change is ready to land so I might try and go with that approach.

[Hahnfeld]

In D47169#1141852, @phosek wrote:

There's another solution that's simpler than the two mentioned above which would be to simply avoid using the compiler-rt logic for determining the set of supported targets and instead rely on CMake which is already what runtimes/ build does except for the host (it's the COMPILER_RT_DEFAULT_TARGET_ONLY option). I know which targets I want to build runtimes for, I don't want CMake to go on and try guessing which targets my compiler may or may not support. This needs D45604 but that change is ready to land so I might try and go with that approach.

I think that should work: Overriding the detection if runtimes/ is known to produce the required dependencies. I don't see how this relies on D45604, but I might be missing something here.

compiler-rt/trunk/cmake/Modules/CompilerRTUtils.cmake

 
 # test_target_arch(<arch> <def> <target flags...>)
 # Checks if architecture is supported: runs host compiler with provided
 # flags to verify that:
 #   1) <def> is defined (if non-empty)
 #   2) simple file can be successfully built.
 # If successful, saves target flags for this architecture.
 macro(test_target_arch arch def)
+  string(RANDOM TARGET_${arch}_NAME)
+  set(TARGET_${arch}_NAME "${CMAKE_BINARY_DIR}${CMAKE_FILES_DIRECTORY}/cmTC_${TARGET_${arch}_NAME}.dir")
+  file(MAKE_DIRECTORY ${TARGET_${arch}_NAME})
+  if(SANITIZER_CXX_ABI_INTREE)
+    # We're using in tree C++ ABI, only test the C compiler for now.
+    set(TARGET_${arch}_FILENAME "${TARGET_${arch}_NAME}/CheckTarget.c")
+    file(WRITE "${TARGET_${arch}_FILENAME}" "#include <stdlib.h>\nint main() { void *p = malloc(1); return 0; }\n")
+  else()
+    # We're using the system C++ ABI, test that we can build C++ programs.
+    set(TARGET_${arch}_FILENAME "${TARGET_${arch}_NAME}/CheckTarget.cpp")
+    file(WRITE "${TARGET_${arch}_FILENAME}" "#include <new>\nint main() { int *p = new int; return 0; }\n")
+  endif()
+
   set(TARGET_${arch}_CFLAGS ${ARGN})
   set(TARGET_${arch}_LINK_FLAGS ${ARGN})
   set(argstring "")
   foreach(arg ${ARGN})
     set(argstring "${argstring} ${arg}")
   endforeach()
   check_compile_definition("${def}" "${argstring}" HAS_${arch}_DEF)
   if(NOT DEFINED CAN_TARGET_${arch})
     if(NOT HAS_${arch}_DEF)
       set(CAN_TARGET_${arch} FALSE)
     elseif(TEST_COMPILE_ONLY)
       try_compile_only(CAN_TARGET_${arch} ${TARGET_${arch}_CFLAGS})
     else()
       set(FLAG_NO_EXCEPTIONS "")
       if(COMPILER_RT_HAS_FNO_EXCEPTIONS_FLAG)
         set(FLAG_NO_EXCEPTIONS " -fno-exceptions ")
       endif()
       set(SAVED_CMAKE_EXE_LINKER_FLAGS ${CMAKE_EXE_LINKER_FLAGS})
       set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} ${argstring}")
-      try_compile(CAN_TARGET_${arch} ${CMAKE_BINARY_DIR} ${SIMPLE_SOURCE}
+      try_compile(CAN_TARGET_${arch} ${CMAKE_BINARY_DIR} ${TARGET_${arch}_FILENAME}
                   COMPILE_DEFINITIONS "${TARGET_${arch}_CFLAGS} ${FLAG_NO_EXCEPTIONS}"
                   OUTPUT_VARIABLE TARGET_${arch}_OUTPUT)
       set(CMAKE_EXE_LINKER_FLAGS ${SAVED_CMAKE_EXE_LINKER_FLAGS})
     endif()
   endif()
   if(${CAN_TARGET_${arch}})
     list(APPEND COMPILER_RT_SUPPORTED_ARCH ${arch})
   elseif("${COMPILER_RT_DEFAULT_TARGET_ARCH}" STREQUAL "${arch}" AND
          COMPILER_RT_HAS_EXPLICIT_DEFAULT_TARGET_TRIPLE)
     # Bail out if we cannot target the architecture we plan to test.
     message(FATAL_ERROR "Cannot compile for ${arch}:\n${TARGET_${arch}_OUTPUT}")
   endif()
+
+  file(REMOVE_RECURSE ${TARGET_${arch}_NAME})
 endmacro()
 
 macro(detect_target_arch)
   check_symbol_exists(__arm__ "" __ARM)
   check_symbol_exists(__aarch64__ "" __AARCH64)
   check_symbol_exists(__x86_64__ "" __X86_64)
   check_symbol_exists(__i386__ "" __I386)
   check_symbol_exists(__mips__ "" __MIPS)

compiler-rt/trunk/cmake/config-ix.cmake

if(ANDROID)
   check_library_exists(log __android_log_write "" COMPILER_RT_HAS_LIBLOG)
 endif()
 
 # Architectures.
 
 # 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 <stdio.h>\nint main() { printf(\"hello, world\"); }\n")
-
 # Detect whether the current target platform is 32-bit or 64-bit, and setup
 # the correct commandline flags needed to attempt to target 32-bit and 64-bit.
 if (NOT CMAKE_SIZEOF_VOID_P EQUAL 4 AND
     NOT CMAKE_SIZEOF_VOID_P EQUAL 8)
   message(FATAL_ERROR "Please use architecture with 4 or 8 byte pointers.")
 endif()
 
 test_targets()