Differential D58013
[compiler-rt] Build custom libcxx with libcxxabi Authored by Hahnfeld on Feb 10 2019, 3:58 AM.
Details
This changes add_custom_libcxx to also build libcxxabi and merges
Diff Detail Event Timeline
Comment Actions @phosek Excellent idea. I tried to implement what you described and it seems to work great! The only minor disadvantage is that we now need to disable the tests if COMPILER_RT_LIBCXXABI_PATH is not found... Comment Actions This is awesome, exactly what I had in mind, thank you so much for working on this!
Comment Actions I needed to push rCRT354231 to fix the sanitizer bots. Let me know if this change is appropriate or want me to revert. In that case we need to run another round of clobber builds to fix CMake configuration (needed because the patch changes the source directory for ExternalProject_Add). Comment Actions This also broke our toolchain builders. The relevant part of the log is: [357/763] Performing configure step for 'libcxx_fuzzer_aarch64' -- The C compiler identification is Clang 9.0.0 -- The CXX compiler identification is Clang 9.0.0 -- Check for working C compiler: /b/s/w/ir/kitchen-workdir/recipe_cleanup/clangrCZ026/llvm_build_dir/./bin/clang -- Check for working C compiler: /b/s/w/ir/kitchen-workdir/recipe_cleanup/clangrCZ026/llvm_build_dir/./bin/clang -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Detecting C compile features -- Detecting C compile features - done -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - failed -- Detecting CXX compile features -- Detecting CXX compile features - failed -- Configuring for standalone build. -- Linker detection: LLD -- Performing Test LLVM_LIBSTDCXX_MIN -- Performing Test LLVM_LIBSTDCXX_MIN - Failed CMake Error at /b/s/w/ir/kitchen-workdir/llvm-project/llvm/cmake/modules/CheckCompilerVersion.cmake:72 (message): libstdc++ version must be at least 4.8. Call Stack (most recent call first): /b/s/w/ir/kitchen-workdir/llvm-project/llvm/cmake/modules/HandleLLVMOptions.cmake:9 (include) /b/s/w/ir/kitchen-workdir/llvm-project/libcxxabi/cmake/Modules/HandleOutOfTreeLLVM.cmake:99 (include) /b/s/w/ir/kitchen-workdir/llvm-project/libcxxabi/cmake/Modules/HandleOutOfTreeLLVM.cmake:142 (configure_out_of_tree_llvm) /b/s/w/ir/kitchen-workdir/llvm-project/libcxxabi/CMakeLists.txt:29 (include) -- Configuring incomplete, errors occurred! I don't know yet why the LLVM_LIBSTDCXX_MIN check is failing but I'm going to do a local build to find out. Comment Actions I found the issue, but I don't know how to easily solve this. The problem is that when being built in standalone mode, libc++abi and libc++ includes LLVM's HandleLLVMOptions which uses checks that try to link C++ library, but that may not be ready yet in case of the runtimes build. In runtimes build I solve this by [adding -nostdlib++ to required flags](https://github.com/llvm/llvm-project/blob/master/llvm/runtimes/CMakeLists.txt#L100). I can do that because in case of runtimes build I know that we'll be always using the just built Clang that supports that flag. I could address this issue by also including -nostdlib++ in required flags in compiler-rt/cmake/Modules/CustomLibcxx/CMakeLists.txt but that's not a general solution because that file in theory also supports other compilers that may not have this flag (older Clang versions, GCC). We could try and use -nostdlib and then include builtins manually but that's a lot of extra code that would need to be duplicated to handle cases like compiler-rt builtins and libgcc. The general solution is to stop relying on checks that assume working C++ library from runtimes (it's where we're building C++ library after all, we should assume a working C++ library), but that's going to require more significant refactor and I'd like to unbreak our bots ASAP so we'll need some other solution. Comment Actions @phosek Sorry for the breakage. I guess there are just too many configurations for non-trivial changes to the build system :-/ | ||||||||||||||||||||||||||||||
I've also tried to remove the ABI namespace (and adjusting LIBFUZZER_CFLAGS) but that resulted in Segfaults during runtime. From a first look it appeared that some relocations were broken in the binary, resulting in calling address 0x0, but I'll need to investigate. I'd say that's out of the scope of this patch anyway.