as detailed within, adding `asm/ptrace.h` leads to `asm/ptrace-abi.h`
being included which defines preprocessor symbols that clash with
identifiers used in the LLVM headers (`FS` and `CS` only defined on
i686)
This restores this check to what it originally was in #196909 (see:
https://github.com/NixOS/nixpkgs/pull/196909#discussion_r1000536298) and
lets `compiler-rt` eval successfully when trying to compile the
`llvmPackages_15` set for mingw targets (i.e. a platform that *is* GNU
but does *not* use glibc).
---
It's not clear to me what the `haveLibc` check is doing here (platforms
that seem to use glibc like `x86_64-linux` and have
`plat.libc == "glibc"` have `haveLibc = false` because `stdenv.cc.libc`
is `null`).
libc++ has switched to using `__attribute__((using_if_exists))` to handle
incomplete libc implementations; see: a9c9183ca4
These essentially require a modern C++ compiler (clang gained support in
LLVM 13: 369c648399,
gcc appears to not have support yet: https://gcc.gnu.org/bugzilla//show_bug.cgi?id=105584).
Previously this was not an issue for us (despite the transition happening
around LLVM 13) but something about the changes to the libc++/libc++-abi
build has made it so that on platforms with incomplete libc impls (i.e.
Darwin is missing `quick_exit`/`at_quick_exit`) we error during the `libcxx-abi`
build when the stdenv's (older, not supporting `using_if_exists`) compiler
tries to import libc symbols that aren't present.
The libc++ docs suggest we use a modern compiler to build libc++ anyways
(https://releases.llvm.org/15.0.0/projects/libcxx/docs/index.html#platform-and-compiler-support)
so this commit uses stdenv's containing the package set's clang to build
libcxx/libcxx-abi.
This is similar to how libc++ bootstrapping builds (https://releases.llvm.org/15.0.0/projects/libcxx/docs/BuildingLibcxx.html#bootstrapping-build)
work.
None of the patches required any touch-up; the only change of note is:
- due to changes in the libc++/libc++abi build
(https://reviews.llvm.org/D120719 and https://reviews.llvm.org/D131037)
we have to add an extra build option to the libc++ header only
build that sidesteps bits of the libc++ build config that assume
libc++-abi is present in the build:
4f827318e3/libcxx/src/CMakeLists.txt (L255-L256)
Rather than maintaining a precise set of build options that let us dodge
referencing libc++-abi variables in the libc++ header only build, we set
`LIBCXX_CXX_ABI` to `none`, as suggested by @lovesegfault.
More discussion about this here: https://github.com/NixOS/nixpkgs/pull/194634#discussion_r990267037
Co-authored-by: Bernardo Meurer <bernardo@meurer.org>
