The test suite leads to nothing but tears, sorrow, and wasted build
time. It probably should be disabled for all of them but doing only
9 (llvmPackages) and 11 (llvmPackages_latest, Rust) for now. Some of
the failures have been fixed in LLVM main:
- https://reviews.llvm.org/D97490
- https://reviews.llvm.org/D91043
This is in an effort to fix the following build failure shown by
chromium:
clang++: error: no such file or directory: '/nix/store/fhd89wrmkx6nflzjk0d6waz70bk3zc4i-clang-wrapper-12.0.0/resource-root/share/cfi_blacklist.txt'
As it turns out a change introduced via the gnu-install-dirs.patch
caused `add_compiler_rt_resource_file` to install resource files to
$dev/include (FULL_INCLUDEDIR) instead of $out/share (FULL_DATADIR)
which in turn meant that the clang wrappers we had didn't link those
files to its resource root at all.
Alternative fix to this would have been to link
compiler-rt.dev/include/*.txt to the wrappers resource-root/share as
well, but since this was handled inconsistently across the patch anyways
(the dfsan list is installed correctly), opt to handle this
consistently within the patch.
llvmPackages_{5,6} install the resource files to a completely different
location and need separate investigation.
7869d16545 changed how resource files are
installed. Likely by accident, now some of the resource files are
installed to $dev/include instead of $out/share. This causes the cc
wrapper's resource-root to miss those files from compiler-rt as they are
in a different place than expected.
This commit fixes all instances of this incorrect installation for
llvmPackages_10, 11 and 12 which are the only llvm package sets which
link ${targetLlvmLibraries.compiler-rt.out}/share to the resource-root.
For the other llvm package set this will likely also need to be fixed,
but it doesn't have to have immediate urgency and doing it in two steps
allows us to (hopefully) fix the chromium build without causing a darwin
stdenv rebuild.
The full fix can be found in #123103 and should probably be included in
the next staging-next rotation.
This will begin the process of breaking up the `useLLVM` monolith. That
is good in general, but I hope will be good for NetBSD and Darwin in
particular.
Co-authored-by: sterni <sternenseemann@systemli.org>
lld needs LLVM's libunwind for its headers. That libunwind is not part
of the tools scope in pkgs/development/compilers/llvm/12/default.nix,
which means that lld previously received libunwind from top-level pkgs
which of course doesn't have the required headers.
To resolve this pass libunwind from the libraries scope — platform
concerns don't really mattern as only libunwind.src is used.
libunwind was initially passed correctly, but that was removed in
e830db4320. This regression was likely
introduced accidentally.
The bintools argument received a wrapped version of tools.bintools which
is already wrapped. Wrapped bintools twice leads to users of lldClang
being unable to find the tools which are not wrapped like ar.
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
- Introduce `preLibcCrossHeaders` to bootstrap libgcc and compiler-rt
the same way.
- Organize LLVM bintools as `bintools{-unwrapped,,NoLibc}` for
consistency with GNU Binutils and Apple's cctools.
- Do Android changes for all `llvmPackages` for consistency.
- Improve the way the default GCC and LLVM versions are selected.
This PR adds a new aarch64 android toolchain, which leverages the
existing crossSystem infrastructure and LLVM builders to generate a
working toolchain with minimal prebuilt components.
The only thing that is prebuilt is the bionic libc. This is because it
is practically impossible to compile bionic outside of an AOSP tree. I
tried and failed, braver souls may prevail. For now I just grab the
relevant binaries from https://android.googlesource.com/.
I also grab the msm kernel sources from there to generate headers. I've
included a minor patch to the existing kernel-headers derivation in
order to expose an internal function.
Everything else, from binutils up, is using stock code. Many thanks to
@Ericson2314 for his help on this, and for building such a powerful
system in the first place!
One motivation for this is to be able to build a toolchain which will
work on an aarch64 linux machine. To my knowledge, there is no existing
toolchain for an aarch64-linux builder and an aarch64-android target.
In 7869d16545 I got rid of the symlinking
by forcing `COMPILER_RT_OS_DIR` to always be the empty string. I thought
this was good because it just make compiler-rt be installed in a normal
way.
However, various LLVM tools expect the `COMPILER_RT_OS_DIR` to be set
normally, and fail to find things when they aren't in the expected lib
subdir.
Maybe it would be best to patch that too in the long term, but for now
we just undo this change.
Before, clang was able to find some headers with a relative path to the
`-B` flag pointing near the unwrapped clang binary. But with multiple
outputs that doesn't work, so we use a "resource directory" as it done
later in the bootstrap.
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.
In 486e12ad68 cmake flags were added matching
later compilers use of libunwind for `useLLVM = true`. Unfortunately, `useLLVM`
on Darwin was not something tested before, and so the other compilers led us
astray: one of the new flags tried to make libunwind be used when it wasn't a
dep.
This is now fixed with more conditional code, but I hope things can perhaps be
made simpler with more insight into why libunwind is skipped. Perhaps it is
included in libSystem?
Finally, I moved the definition of `cmakeFlags` to match the order in the other
llvm versions.
CC @sternenseemann and @thefloweringash
This flag was introduced for clang 9, but we use it in the `lldClang`
wrapper for `llvmPackages` 7, 8 and 9. For this purpose the patch was
backported for `llvmPackages_8.clang`, but not for `llvmPackages_7.clang`
which has been done in this commit.
`lldClang` is mostly used when cross compiling and
`stdenv.hostPlatform.useLLVM` is true. Most likely this problem wasn't
noticed since `useLLVM` with `llvmPackages_7` was broken for other
reasons as well and all cross targets (like `wasi32`) which have
`useLLVM` at the moment use `llvmPackages_8`.
With this change tests.cross.llvm.hello.{musl64, …} works again.
This reverts commit 76b54c75b3 and brings
llvmPackages_7.libcxxabi in line with what the other llvmPackages
sets are doing again (with llvmPackages_7 being the sole outlier).
This also fixes an evaluation error of llvmPackages_7.libcxxabi if
stdenv.hostPlatform.useLLVM is true as the nonexistant libunwind
argument would be overridden.
This commit patches one of the llvm-exegesis tests to swap out whatever
CPU model happens to be on the build host for bdver2 (AMD Family
15h/Piledriver), which was picked because it looks like that was the
intent of the test author. This provides a more predictable compilation
behaviour when running on older (or possibly even newer!) machines.
One of the machines that is currently part of the NixOS Hydra build
farm, wendy, is using an old AMD Opteron CPU for which LLVM has no
scheduling machine model. This causes one of the tests for llvm-exegesis
to fail, because it segfaults trying to use the machine model to produce
useful analysis results.
Note that this particular test only runs on x86-64 build hosts anyway;
aarch64 isn't affected.
This deliberately only patches LLVM 12 to limit the rebuilds; other
LLVM versions are going through staging.
This patches are included from libcxx and libcxxabi when
stdenv.hostPlatform.isMusl. After #117433 the patchs to that patch
wasn't adjusted for the new structure, likely because it doesn't come up
during normal eval. This fixes (among other attribute paths):
* pkgsMusl.llvmPackages_12.libcxxabi
* pkgsMusl.llvmPackages_12.libcxx
* pkgsMusl.llvmPackages_11.libcxxabi
* pkgsMusl.llvmPackages_11.libcxx
* pkgsMusl.llvmPackages_10.libcxxabi
* pkgsMusl.llvmPackages_10.libcxx
* pkgsMusl.llvmPackages_9.libcxxabi
* pkgsMusl.llvmPackages_9.libcxx
* pkgsMusl.llvmPackages_8.libcxxabi
* pkgsMusl.llvmPackages_8.libcxx
* pkgsMusl.llvmPackages_7.libcxxabi
* pkgsMusl.llvmPackages_7.libcxx
* pkgsMusl.llvmPackages_6.libcxxabi
* pkgsMusl.llvmPackages_6.libcxx
* pkgsMusl.llvmPackages_5.libcxxabi
* pkgsMusl.llvmPackages_5.libcxx
Only evaluation was tested, not compilation though.
