gcc's configure system has the nasty habit (for us) of judging for
itself if it is building a cross compiler (or cross compiling), but on
the limited information of the build, host and target platforms' config
which only contains a subset of the information we encode in
`stdenv.*Platform`. The practical consequence was that prior to this
change building `pkgsLLVM.buildPackages.gcc` actually fails because it
refuses to use `--with-headers` with something it believes to not be a
cross compiler.
As a workaround we force the appropriate variable in the configure
script to always be `yes` regardless of its own conditional check.
At some point we probably should report this issue in some capacity, so
future gcc versions don't force us into workarounds like this and
acdc783418.
The broken build of ghcHEAD on aarch64-linux results from rts/Libdw.c
not supporting that platform. Seemingly this particular file is only
relevant for DWARF support in GHC, so we disable that on unsupported
platforms.
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.
