This allows the Go compiler in nixpkgs (eg. buildGoModule) to work with
crossSystem.config == mips-*, eg mips-unknown-linux-musl, and
succesfully generate Go MIPS binaries.
nix-build -A grpcurl --arg crossSystem '{ config = "mips-unknown-linux-musl"; }'
This unfortunately cannot currently be tested on qemu-mips as Go emits
ELF files that fail to execute correctly in qemu-user (see:
https://go-review.googlesource.com/c/go/+/239217, on track to land in Go
1.17). However, I have tested this on a physical MIPS device.
I have not been able to build anything using cgo (hit various
compilation errors in C dependencies), but considering
mips-unknown-linux-musl is not a support nixpkgs target this isn't that
surprising.
packagePaths changed between idris2 `v0.3.0` and `v0.4.0` and now
includes a version number in the path.
Fixesnixos/nixpkgs#130310
Co-authored-by: zseri <zseri.devel@ytrizja.de>
Co-authored-by: Mario Rodas <marsam@users.noreply.github.com>
The musl support for binary GHC 8.6.5 relied on ABI compat between musl
and glibc which is no longer the case: https://github.com/NixOS/nixpkgs/issues/129247
Since there is no upstream musl (alpine) bindist for GHC 8.6.5, we can
only accept that binary 8.6.5 is not possible with musl.
There are builds which rely on having the numeric version of gcc (eg "10.2.1")
declared in an environment variable.
Running 'arm-none-eabi-gcc --version' returns:
"arm-none-eabi-gcc (GNU Arm Embedded Toolchain 10-2020-q4-major) 10.2.1 20201103 (release)"
However, the attribute arm-none-eabi-gcc.version is "10-2020-q4-major",
from which there is no way to derive "10.2.1".
Contrast this with the attribute gcc.version which (at this time) gives "10.3.0".
By adding a numVersion attribute, consumers of this package can
correctly determine what GCC version is being executed.
Signed-off-by: Sirio Balmelli <sirio@b-ad.ch>
