Open solidDoWant opened 1 year ago
The proper way to do this IMO is to provide a CMake interface target representing the C library that we can link against, and to allow replacing that. Similarly to how we allow the C++ ABI library to be customized in https://github.com/llvm/llvm-project/blob/d617371375cba53e44eccedbac976f2b74df4f23/libcxx/cmake/Modules/HandleLibCXXABI.cmake
Specifying the
LIBCXX_HAS_MUSL_LIBC
flag requires Musl libc headers to be installed and resolvable by the compiler when building libc++. When building libc++ as a runtime there is not currently a way to configure CMake to include a specific directory in the header search path. As a result, it does not appear to be possible to build a toolchain with libc++ support for Musl libc when the headers for the specific version of Musl libc needed are not installed onto the build host. For example it does not seem to be possible to use a build system with tripletx86_64-pc-linux-gnu
to build toolchain that targetsx86_64-pc-linux-musl
without first installing the Musl headers onto the build system.I have attempted to get around this issue by setting both
CMAKE_C_FLAGS
andCMAKE_CXX_FLAGS
to-isystem/path/to/musl/headers
, but this value does not get passed down to the runtimes because the runtimes are loaded in CMake via anadd_subdirectory
directive here which does not preserve variable scope. TheCOMPILER_RT_CMAKE_CXX_FLAGS
flag is passed down to the runtime cmake files, but the generated build files do not include the flag when invoking the compiler.