There is no "aarch64" CPU family — it counts as "arm", as can be seen
from the definition of isAarch64 above.
Checked that stdenv.hostPlatform.isEfi is still true on aarch64-linux.
In the past, most (if not all) armv8 CPUs could also execute armv7. However,
with the advent of Apple Silicon, aarch64 CPUs without any aarch32 capabilities
are now wide-spread among users.
Cross-compilation of anything downstream of gtk3 requires qemu (due to
gobject-introspection) with --target-list=*-linux-user. Without this commit,
those qemu builds will fail on a powerpc64le host due to qemu being configured
with --cpu=powerpc64le instead of --cpu=ppc64le. Unfortunately the build
failure message from qemu in this situation is extremely cryptic.
The root cause turns out not to be the qemu expression, but rather the fact that
on powerpc64le hostPlatform.uname.processor returns the gnu-name (powerpc64le)
for the cpu instead of the linux-name (ppc64le) for the cpu.
uname.processor on mips64el also needs adjustment -- the Linux-name is "mips64"
for both big and little endian (unlike powerpc64, where the Linux-name includes
a "le" suffix):
```
nix@oak:/tmp$ uname -m; lscpu | head -n2
mips64
Architecture: mips64
Byte Order: Little Endian
```
uname.processor on powerpc32 has also been adjusted.
The main purpose of this PR is to make the basis for
`mkSkeletonFromList`'s decision between `cpu-kernel-libcabi` vs
`cpu-vendor-os` clear, without changing its behavior. The existing
code obscures this decision behind a sequence of prioritized matches
(i.e. `if-then`) which jump around between different coordinates.
Two side benefits of this PR:
1. It makes the root cause of #165836 obvious: we are missing a case
for `cpu-vendor-libcabi`. This is why nixpkgs stumbles over
`*-none-*`.
2. It illuminates some very weird corner cases in the existing
logic, like `*-${vendor}-ghcjs` overriding the `vendor` field,
and `mingw32` being transformed into `windows` in some cases.
Co-authored-by: John Ericson <git@JohnEricson.me>
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.
Move already implemented functionality to the upper level so
it could be used in a more generic way.
Signed-off-by: Ivan Nikolaenko <ivan.nikolaenko@unikie.com>
```
nix-repl> pkgsCross.arm-embedded.stdenv.hostPlatform.emulatorAvailable pkgsCross.arm-embedded.buildPackages
false
nix-repl> pkgsCross.aarch64-multiplatform.stdenv.hostPlatform.emulatorAvailable pkgsCross.aarch64-multiplatform.buildPackages
true
```
will be useful for stuff like handling https://github.com/NixOS/nixpkgs/issues/187109
The comment in lib/systems/default.nix for uname.processor indicates that it
should match `uname -p`. I tried that command and found that it reports
`unknown` on all of these machines:
- `x86_64-linux`
- `aarch64-linux`
- `mips64el-linux`
- `powerpc64le-linux`
The command `uname -m` reports the expected value on all of the above.
I think the comment is wrong. So I fixed it.
In Nixpkgs, we assume that the "config" field is a canonicalized GNU
triple. I noticed that non-canonical values were being used here,
because the pkgsCross.mips64el-linux-gnu triples did not contain the
vendor field, but the pkgsCross.mips64el-linux-gnu.pkgsStatic did.
Here, I've run all the MIPS triples in lib.systems.examples through
config.sub to canonicalize them. I think this will avoid nasty
surprises in future.
Tested by building Nix and the bootstrap files for
pkgsCross.mips64el-linux-gnu.
This has been deprecated for a long time, and it's doubtful it had any
users to start with. And having an undisablable warning when
enumarating platforms is not good.
These servers apparently no longer exist, since September 2, 2021[1].
If somebody needs this for non-Scaleway machines, they should suggest
its reintroduction with a different name.
[1]: https://news.ycombinator.com/item?id=27192757
