Add a new `aarch64-freebsd` double and example system,
then fix include and libc to work.
This is enough to build packages like `hello`,
either static or dynamic.
This is useful for testing nix FreeBSD on a Raspberry Pi.
When elaborating a system with both "config" and "system" arguments
given, they might not match the parsed results. Example:
elaborate {
config = "i686-unknown-linux-gnu";
system = "x86_64-linux";
}
This would result in a parsed system for i686, because the config
argument is preferred. But since "// args //" comes after system has
been inferred from parsed, it is overwritten again. This results in
config and parsed all pointing to i686, while system still tells the
story of x86_64.
Inconsistent arguments can also be given when passing "parsed" directly.
This happened in stage.nix for the various package sets.
The solution is simple: One of the three arguments needs to be treated
as the ultimate source of truth. "system" can already be losslessly
extracted from "parsed". However, "config" currently can not, for
example for various -mingw32 cases. Thus everything must be derived
from "config".
To do so, "system" and "parsed" arguments are made non-overrideable for
systems.elaborate. This means, that "system" will be used to parse when
"config" is not given - and "parsed" will be ignored entirely.
The systemToAttrs helper is exposed on lib.systems, because it's useful
to deal with top-level localSystem / crossSystem arguments elsewhere.
toLosslessStringMaybe is not used by anything other than lib/tests,
so it can be private to that file.
I don't think this function was terribly well thought-through. If
people start using it, we will become permanently dependent on the
ability to test platforms for equality. It also makes the
elaboration process more fragile, because it encourages code outside
of nixpkgs to become sensitive to the minute details of how
elaboration happens.
We already have examples for these, but since we didn't actually
recognise the doubles, it wasn't possible to build any packages for
them without setting allowUnsupportedSystem.
A tricky thing about FreeBSD is that there is no stable ABI across
versions. That means that putting in the version as part of the config
string is paramount.
We have a parsed represenation that separates name versus version to
accomplish this. We include FreeBSD versions 12 and 13 to demonstrate
how it works.
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.
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.
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.
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.)
PPC64 supports two ABIs: ELF v1 and v2.
ELFv1 is historically what GCC and most packages expect, but this is
changing because musl outright does not work with ELFv1. So any distro
which uses musl must use ELFv2. Many other platforms are moving to ELFv2
too, such as FreeBSD (as of v13) and Gentoo (as of late 2020).
Since we use musl extensively, let's default to ELFv2.
Nix gives us the power to specify this declaratively for the entire
system, so ELFv1 is not dropped entirely. It can be specified explicitly
in the target config, e.g. "powerpc64-unknown-linux-elfv1". Otherwise the
default is "powerpc64-unknown-linux-elfv2". For musl,
"powerpc64-unknown-linux-musl" must use elfv2 internally to function.
This reverts commit ce2f74df2c.
Doubles are treated as -darwin here, to provide some consistency.
There is some ambiguity between “x86_64-darwin” and “i686-darwin”
which could refer to binaries linked between iOS simulator or real
macOS binaries. useiOSPrebuilt can be used to determine which to use,
however.
This has been not touched in 6 years. Let's remove it to cause less
problems when adding new cross-compiling infrastructure.
This also simplify gcc significantly.
Existing "mips64el" should be "mipsel".
This is just the barest minimum so that nixpkgs can recognize them as
systems - although required for building individual derivations onto
MIPS boards, it is not sufficient if you want to actually build nixos on
those targets
The old hard-coded lists are now used to test system parsing.
In the process, make an `assertTrue` in release lib for eval tests; also
use it in release-cross
