Apparently this does not depend on stdenv's macOS SDK at all,
and carries around its own go-specific toolchain. So this works
fine as-is and doesn't need any changes in Nixpkgs to support a
10.13 deployment target.
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.
Because:
* `go-bootstrap` is a native build input of go, so it needs to have
an offset of -1. Otherwise, e.g. when building a go cross-compiler,
it will try to make go-bootstrap a cross-compiler too.
* have to specify `buildPackages` for the `stdenv` override, otherwise
`buildPackages.stdenv` will be the same as `pkgs.gcc8Stdenv`.
Changes are minor - I ended up just patching the ssl certs at the root
file, rather than trying to keep up with the various darwin changes.
The externalnetwork test helper location changed, to so I had to update
that patch as well.
- Add xcbuild as propagatedBuildInput on darwin 7e25bdba5e
continuation of #109595
pkgconfig was aliased in 2018, however, it remained in
all-packages.nix due to its wide usage. This cleans
up the remaining references to pkgs.pkgsconfig and
moves the entry to aliases.nix.
python3Packages.pkgconfig remained unchanged because
it's the canonical name of the upstream package
on pypi.
This is used in https://github.com/tweag/gomod2nix to reconstruct a
vendor metadata file.
With the vendor checks we need a lot more metadata which isn't
relevant for building packages, especially since we've already locked
the dependency graph ahead of time
This has been ported from FreeBSD: https://reviews.freebsd.org/D24122
Otavio Salvador