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. |
||
---|---|---|
.. | ||
always-search-rpath.patch | ||
build-components-separately.patch | ||
CVE-2020-35448.patch | ||
default.nix | ||
deterministic.patch | ||
disambiguate-arm-targets.patch | ||
R_ARM_COPY.patch | ||
support-ios.patch |