This patch causes the autodetection code in lib/systems/platforms.nix
to return {} if it cannot detect the platform and one of the
platform.nix-detection-provided attributes (linux-kernel, gcc, and
rustc) are accessed, rather than silently assuming the "pc" platform
as was previously done.
It is definitely safe to assume that code using these attributes is
prepared to deal with `gcc` and `rustc` not being defined, because
many of the working entries in this file don't define it.
Regarding `linux-kernel` the situation is less certain, but some code
(`lib/systems/default.nix` for example) is already designed to deal
with that attribute being missing. At worst it would result in an
"attribute not found" error.
While adding mips64el bootstrap support to nixpkgs, the silent
assumption that mips64el routers are actually Intel PCs caused
significant frustration. This commit removes that assumption in order
to save people who port nixpkgs to new platforms in the future from
this frustration.
For other platforms like Intel and ARM, we can do
e.g. lib.platforms.aarch64 to get only the 64-bit ARM platorms, but
until now there were no equivalents for RISC-V.
This commit adds an `isPower64` predicate to the two existing
predicates for this architecture (`isPower` and `isPowerPC`).
Note that `isPowerPC` matches only 32-bit machines, whereas `isPower`
matches both 64-bit and 32-bit machines. Prior to this commit there
was no single `isXXX` predicate for `powerpc64le`.
MIPS has a large space of {architecture,abi,endianness}; this commit
adds all of them to lib/systems/platforms.nix so we can be done with
it.
Currently lib/systems/inspect.nix has a single "isMips" predicate,
which is a bit ambiguous now that we will have both mips32 and mips64
support, with the latter having two ABIs. Let's add four new
predicates (isMips32, isMips64, isMips64n32, and isMips64n64) and
treat the now-ambiguous isMips as deprecated in favor of the
more-specific predicates. These predicates are used mainly for
enabling/disabling target-specific workarounds, and it is extremely
rare that a platform-specific workaround is needed, and both mips32
and mips64 need exactly the same workaround.
The separate predicates (isMips64n32 and isMips64n64) for ABI
distinctions are, unfortunately, useful. Boost's user-scheduled
threading (used by nix) does does not currently supports mips64n32,
which is a very desirable ABI on routers since they rarely have
more than 2**32 bytes of DRAM.
While it is a fact of life that aarch64-darwin is built on Hydra, it has
never formally been elevated from the Tier 7 state it was originally
assigned in RFC 0046. Since platform Tier status is not only
descriptive, but also normative, a consensus to commit to supporting
aarch64-darwin would need to be reached.
PowerNV was looking for a nonexisting zImage file.
Remove unnecessary .file / .installTarget.
Also add config options needed for default minimal
NixOS config and QEMU VirtIO/VirtFS devices.
This allows checking e.g. stdenv.hostPlatform.isGnu, just like isMusl
or isUClibc. It was already possible to check for glibc with
stdenv.hostPlatform.libc == "glibc", but when that doesn't line up
with how every other platform check works, this is apparently
sufficiently non-obvious that we've ended up with stuff like adding
glibc.static if !isMusl, which is obviously wrong.
This regressed in 9c213398b3
The recursiveUpdate gave the platform both gcc.cpu and gcc.arch attrs
instead of only gcc.cpu. This is invalid; gcc configuration fails with:
```
Switch "--with-arch" may not be used with switch "--with-cpu"
```
So we revert to using `//` to retain only gcc.cpu
(which is more specific than the processor arch).
m68k was recently added for Linux and none, but NetBSD also supports
m68k. Nothing will build yet, but I want to make sure we at least
encode the existence of NetBSD support for every applicable
architecture we support for other operating systems.
In Autoconf, some old NetBSD targets like "i686-unknown-netbsd" are
interpreted as a.out, not elf, and virtually nothing supports it. We
need to specify e.g. "i686-unknown-netbsdelf" to get the right
behaviour.
Newer bootloaders for RISC-V (i.e., OpenSBI + U-Boot) support
flat and compressed kernel images but not vmlinux. Therefore,
let's build "Image" like what we do with aarch64.
Also copy DTBs while we are at it.
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>
Stating that CPUs and the isCompatible relation forms a category (or
preorder) is correct but overtly technical. We can state it more
clearly for readers unfamiliar with mathematics while retaining some
keywords to be useful to technical readers.
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.
These are all the architectures supported by Nixpkgs on other
platforms, that are also supported by NetBSD. (So I haven't added
any architectures that are new to Nixpkgs here, even though NetBSD
supports some that we don't have.)
The previous mess was partially grouped by OS, and partially grouped
by architecture, which made it very difficult to know where to add new
entries.
I've chosen to group by OS entirely, because OSes are likely to
maintain exhaustive lists of supported architectures, but it's far
less likely we'd be able to find exhaustive lists of supported OSes
for every architecture.
yvt