LLVM 11 libcxxabi has some flags to support usage in the Darwin stdenv,
in particular, `standalone` and `withLibunwind`.
Darwin stdenv needs the `standalone` flag because its `hostPlatform` set
doesn't have `useLLVM` set to true. And it needs `withLibunwind` to
explicitly disable including `libunwind` as a build input.
We also prefix `install_name_tool` in case we're cross-compiling.
The main thing was using `llvm_meta` in all versions.
Secondarily:
- libunwindx7: Forgot to split outputs
- libcxx{,abi} 12: Forgot to apply output-splitting patches.
- simplify `useLLVM` stdenv-switching logic.
- openmp always gets its own directory
Also begin to start work on cross compilation, though that will have to
be finished later.
The patches are based on the first version of
https://reviews.llvm.org/D99484. It's very annoying to do the
back-porting but the review has uncovered nothing super major so I'm
fine sticking with what I've got.
Beyond making the outputs work, I also strove to re-sync the packages,
as they have been drifting pointlessly apart for some time.
----
Other misc notes, highly incomplete
- lvm-config-native and llvm-config are put in `dev` because they are
tools just for build time.
- Clang no longer has an lld dep. That was introduced in
db29857eb3, but if clang needs help
finding lld when it is used we should just pass it flags / put in the
resource dir. Providing it at build time increases critical path
length for no good reason.
----
A note on `nativeCC`:
`stdenv` takes tools from the previous stage, so:
1. `pkgsBuildBuild`: `(?1, x, x)`
2. `pkgsBuildBuild.stdenv.cc`: `(?0, ?1, x)`
while:
1. `pkgsBuildBuild`: `(?1, x, x)`
2. `pkgsBuildBuild.targetPackages`: `(x, x, ?2)`
3. `pkgsBuildBuild.targetPackages.stdenv.cc`: `(?1, x, x)`
This might be a bit debatable but upstream uses "xx" instead of "++"
when using it as identifier / in the code (file/directory names, build
scripts, website URLs, etc.) so we should probably too.
And at least the attribute name and pname will be consistent now.
toonn