Add test for COMPILER_RT_CAN_EXECUTE_TESTS before using
the just built compiler.
Details
Diff Detail
- Repository
- rCRT Compiler Runtime
- Build Status
Buildable 14014 Build 14014: arc lint + arc unit
Event Timeline
I don't think this is correct, compiling libFuzzer should be unrelated to whether we can execute tests or not. Your just built compiler should be capable of targeting Linux if that's your target platform.
The problem here is that you are using the just built compiler, which may not run on the host if you are cross-compiling. If you take a look at the implementation of add_custom_libcxx, you'll see that it uses the just-built compiler -- -DCMAKE_CXX_COMPILER=${COMPILER_RT_TEST_CXX_COMPILER}.
In my case:
CMAKE_HOST_SYSTEM_NAME=Darwin CMAKE_SYSTEM_NAME=Linux
With the just built compiler built like this: --target=x86_64-unknown-linux-gnu, so it won't run on Darwin.
In that case, I think we should modify add_custom_libcxx and add a new argument USE_TEST_COMPILER, if not set it should use the host compiler (i.e. CMAKE_C_COMPILER and CMAKE_CXX_COMPILER). @vitalybuka WDYT?
Running libFuzzer's tests with the host compiler is a very different thing than running libFuzzer's tests with the just built compiler. I'm pretty sure using CMAKE_C_COMPILER for the tests will more or less just test the fuzzer and sanitizers from your host system, which really isn't useful for testing that the libFuzzer you built works.
Btw, shouldn't this all be hidden behind a test target, e.g., check-libfuzzer or something like that? That way, the just-built compiler is only used when you actually run tests.
With D42330, it's no longer using the just-built compiler, but still fails when cross compiling (host=Darwin, target=Linux).
Temporary workaround: -DBOOTSTRAP_COMPILER_RT_BUILD_LIBFUZZER=OFF