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.
The `platform` field is pointless nesting: it's just stuff that happens
to be defined together, and that should be an implementation detail.
This instead makes `linux-kernel` and `gcc` top level fields in platform
configs. They join `rustc` there [all are optional], which was put there
and not in `platform` in anticipation of a change like this.
`linux-kernel.arch` in particular also becomes `linuxArch`, to match the
other `*Arch`es.
The next step after is this to combine the *specific* machines from
`lib.systems.platforms` with `lib.systems.examples`, keeping just the
"multiplatform" ones for defaulting.
I hate the thing too even though I made it, and rather just get rid of
it. But we can't do that yet. In the meantime, this brings us more
inline with autoconf and will make it slightly easier for me to write a
pkg-config wrapper, which we need.
While it is easy to make a custom kernel by applying kernelPatches it is
not so easy to get the corresponding headers; the derivation uses a
hard-coded kernel version.
This makes us less reliant on the systems/examples.nix. You should be
able to cross compile with just your triple:
$ nix build --arg crossSystem '{ config = "armv6l-unknown-linux-gnueabi"; }' stdenv
Carefully fake cc-version and cc-fullversion to avoid needing a compiler
for the kernel itself to build the headers.
For some reason, doing `make install_headers` twice, first without
INSTALL_HDR_PATH=$out then with, is neccessary to get this to work.
It's not actually needed, and AFAICT has never been. Or at least
Buildroot can build kernel headers as old as 3.2 without running the
config phase.
While at it, set ARCH unconditionally.
@dezgeg was right: The `platform` field of a linux platorm is already
manadatory---if not specified it is inferred, and all such inferences
include a `kernelArch` field. Therefore linux packages can indeed rely
on it being defined.
- Perl is used at build time, so must be in `nativeBuildInputs`. It's
not used at run time so it should not be in `buildInputs`, too.
- Don't treat headers like a compiler---use the build and host
platforms not host and target. Perhaps that would make sense if every
library's headers could be a separate derivation, but since that is
not feasible, best to keep the implementation and interface in the
same stage.
To do this, we used `stdenvNoCC` to get rid of the normal toolchain,
and added a dependency for the toolchain targeting the build platform
--- `buildPackages.stdenv.cc` --- thus everything is effectively slid
a stage black.
Extracting headers from a grsecurity patched kernel triggers additional
build steps that require gcc plugins. For this to work, we'd need to
add gmp, libmpfr, and libmpc to the build inputs as well as run `make
prepare` before installing the headers (lest the build fail due to
missing files).
Out-of-tree modules use kernel.dev and user space should use the Linux
API headers used to build libc, not headers extracted from random
kernels, so fixing this for grsecurity is pointless.
