This makes the targetPrefix always conform to nixpkgs' expectations
instead of relying on the autotools build system to figure it out
correctly (which is also inconsistent across versions).
See also ca9be0511b.
The binutils build system checks by itself if it is building a cross
toolchain or not and prepends or omits a targetPrefix accordingly. This
means that we can always pass target via configureTargets.
However the binutils build system and our bintools wrapper disagree over
whether we are building a cross toolchain or not sometimes since cross
compilation can be relatively subtle in nixpkgs. For example every use
of crossOverlays will make nixpkgs build a cross toolchain even though
localSystem == crossSystem. The cross infrastructure is also used to
build native binaries with a different stdenv (musl instead of glibc,
clang instead of gcc). In all of these cases stdenv.hostPlatform.config
== stdenv.targetPlatform.config, causing binutils to not prepend a
target prefix. At the same time stdenv.hostPlatform !=
stdenv.targetPlatform causing the bintools wrapper to expect a target
prefix, thus building an incomplete set of bintools. This is why
currently pkgsCross.gnu64 and pkgsCross.musl64 aren't working.
The solution is quite simple however: If we detect that we are building
a cross toolchain in the binutils-unwrapped expression, we force the
targetPrefix with --programprefix and fulfill the expectations of the
bintools wrapper at the same time.
Tested (on x86_64-linux):
* pkgsCross.musl64.hello
* pkgsCross.aarch64-multiplatform.hello
* pkgs.hello
Still not working is pkgsCross.gnu64, since
x86_64-unknown-linux-gnu-stage-final-gcc gets confused about targets
now, so bootstrapping the stdenv fails. Since this wasn't working
previously anyways, it's proably fine to fix this separately.
With this change,
nativeBuildInputs = [ bmake ];
will cause bmake to be used instead of GNU make, but with the usual
stdenv API. Packages using bmake will no longer need to implement
their own {build,check,dist}Phase.
