HomePhabricator

[libc++abi] Fix the standalone build after the __config_site change

Authored by ldionne on Oct 22 2020, 4:11 PM.

Description

[libc++abi] Fix the standalone build after the __config_site change

In 5d796645, we stopped looking at the LIBCXXABI_LIBCXX_INCLUDES variable,
which broke users of the Standalone build. This patch reinstates that
variable, however it must point to the *installed* path of the libc++
headers, not the libc++ headers in the source tree (which has always
been the case, but wasn't enforced before).

If LIBCXXABI_LIBCXX_INCLUDES points to the libc++ headers in the source
tree, the __config_site header will fail to be found.

Details

Committed
ldionneOct 22 2020, 4:17 PM
Parents
rG93953d411a0f: [NFC][SampleFDO] Move some common stuff from…
Branches
Unknown
Tags
Unknown

Event Timeline

mstorsjo added inline comments.
/libcxxabi/CMakeLists.txt
153

Just FWIW, MSVC (and clang-cl) can take options preceded either by a slash or a dash - slashes are the canonical spelling but using dashes can simplify some things occasionally. So for options that have the same name in both (/I vs -I) you don't need a cmake conditional.

I think this broke compiler-rt's libcxx_fuzzer (enabling compiler-rt and libcxxabi in the LLVM projects should be enough to reproduce this error):

02:19:00  [2638/5088] cd /var/lib/jenkins/workspace/llvm-master/build/projects/compiler-rt/lib/fuzzer/libcxx_fuzzer_x86_64-bins && /usr/bin/cmake -DCMAKE_SHARED_LINKER_FLAGS= -DCMAKE_MODULE_LINKER_FLAGS= -DCMAKE_EXE_LINKER_FLAGS= -DCMAKE_INSTALL_PREFIX=/usr/local -DCMAKE_MAKE_PROGRAM=/usr/bin/ninja -DCMAKE_LINKER=/usr/bin/ld -DCMAKE_AR=/usr/bin/ar -DCMAKE_RANLIB=/usr/bin/ranlib -DCMAKE_NM=/usr/bin/nm -DCMAKE_OBJCOPY=/usr/bin/objcopy -DCMAKE_OBJDUMP=/usr/bin/objdump -DCMAKE_STRIP=/usr/bin/strip -DCMAKE_C_COMPILER=/usr/bin/clang -DCMAKE_CXX_COMPILER=/usr/bin/clang++ "-DCMAKE_C_FLAGS=-m64 " "-DCMAKE_CXX_FLAGS=-m64 " -DCMAKE_BUILD_TYPE=Release -DCMAKE_TRY_COMPILE_TARGET_TYPE=STATIC_LIBRARY -DLLVM_PATH=/var/lib/jenkins/workspace/llvm-master/llvm-project/llvm -DLLVM_BINARY_DIR=/var/lib/jenkins/workspace/llvm-master/build/projects/compiler-rt/lib/fuzzer/libcxx_fuzzer_x86_64 -DLLVM_LIBRARY_OUTPUT_INTDIR=/var/lib/jenkins/workspace/llvm-master/build/projects/compiler-rt/lib/fuzzer/libcxx_fuzzer_x86_64/lib -DCOMPILER_RT_LIBCXX_PATH=/var/lib/jenkins/workspace/llvm-master/llvm-project/llvm/../libcxx -DCOMPILER_RT_LIBCXXABI_PATH=/var/lib/jenkins/workspace/llvm-master/llvm-project/llvm/../libcxxabi -DCMAKE_CXX_COMPILER_WORKS=ON -DCMAKE_POSITION_INDEPENDENT_CODE=ON -DLIBCXXABI_ENABLE_EXCEPTIONS=OFF -DLIBCXX_ABI_NAMESPACE=__Fuzzer -GNinja /var/lib/jenkins/workspace/llvm-master/llvm-project/compiler-rt/cmake/Modules/CustomLibcxx && /usr/bin/cmake -E touch /var/lib/jenkins/workspace/llvm-master/build/projects/compiler-rt/lib/fuzzer/libcxx_fuzzer_x86_64-stamps//libcxx_fuzzer_x86_64-configure
02:19:00  -- The C compiler identification is Clang 10.0.1
02:19:00  -- The CXX compiler identification is Clang 10.0.1
02:19:00  -- Detecting C compiler ABI info
02:19:01  -- Detecting C compiler ABI info - done
02:19:01  -- Check for working C compiler: /usr/bin/clang - skipped
02:19:01  -- Detecting C compile features
02:19:01  -- Detecting C compile features - done
02:19:01  -- Detecting CXX compiler ABI info
02:19:01  -- Detecting CXX compiler ABI info - done
02:19:01  -- Check for working CXX compiler: /usr/bin/clang++ - skipped
02:19:01  -- Detecting CXX compile features
02:19:01  -- Detecting CXX compile features - done
02:19:01  -- Configuring for standalone build.
02:19:01  -- Linker detection: GNU ld
02:19:01  CMake Error at /var/lib/jenkins/workspace/llvm-master/llvm-project/libcxxabi/CMakeLists.txt:147 (message):
02:19:01    LIBCXXABI_LIBCXX_INCLUDES= is not a valid directory.  Please provide the
02:19:01    path to where the libc++ headers have been installed.
02:19:01

I think this broke compiler-rt's libcxx_fuzzer (enabling compiler-rt and libcxxabi in the LLVM projects should be enough to reproduce this error):

02:19:01  CMake Error at /var/lib/jenkins/workspace/llvm-master/llvm-project/libcxxabi/CMakeLists.txt:147 (message):
02:19:01    LIBCXXABI_LIBCXX_INCLUDES= is not a valid directory.  Please provide the
02:19:01    path to where the libc++ headers have been installed.
02:19:01

I also end up in this situation, if I configure libcxx and install its headers first, and then try to build libcxxabi (without LIBCXXABI_LIBCXX_INCLUDES, which I'd consider unneeded as the headers are installed and found in the compiler's default path at this point). It works if I set LIBCXXABI_LIBCXX_INCLUDES=<prefix>/include/c++/v1, but that's a bit redundant when it's the compiler's default include path. (Or just LIBCXXABI_LIBCXX_INCLUDES=<libcxx-builddir>/include/c++/v1.)

bjope added a subscriber: bjope.Oct 23 2020, 5:21 AM

Our "master integration" also stopped after this commit, and we hit the LIBCXXABI_LIBCXX_INCLUDES= is not a valid directory. error. We've never provided any LIBCXXABI_LIBCXX_INCLUDES so I'm not sure what I should point it to.

I also noticed that LIBCXXABI_STANDALONE_BUILD is set earlier in libcxxabi/CMakeLists.txt (although I'm not sure exactly what defines our build as a standalone build... we just pass {{-DLLVM_ENABLE_RUNTIMES=all}} to cmake, so I don't think we request to build it stand alone).