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.
Instead of always supplying flags, apply the flags as defaults. Use
clang's native flags instead of lifting the linker flags from binutils
with `-Wl,`.
If a project is using clang to drive linking, make clang do the right
thing with MACOSX_DEPLOYMENT_TARGET. This can be overridden by command
line arguments. This will cause modern clang to pass
`-platform_version 10.12 0.0.0`, since it doesn't know about the SDK
settings. Older versions of clang will pass down `-macos_version_min`
flags with no sdk version.
At the linker layer, apply a default value for anything left
ambiguous. If nothing is specified, pass a full
`-platform_version`. If only `-macos_version_min` is specified, then
lock down the sdk_version explicitly with `-sdk_version`. If a min
version and sdk version is passed, do nothing.
We can use use `stdenv.hostPlatform.isStatic` instead, and move the
logic per package. The least opionated benefit of this is that it makes
it much easier to replace packages with modified ones, as there is no
longer any issue of overlay order.
CC @FRidh @matthewbauer
This bug was preventing one compiling Haskell programs from `pkgsMusl` for
armv7.
`nix-build --argstr crossSystem "armv7l-linux" -A pkgsMusl.haskellPackages.hello`
succeeds with this patch.
The patch is Nick Clifton's one, rebased by @ericson2314 here
https://sourceware.org/bugzilla/show_bug.cgi?id=16177#c6
Although there was some talk about the efficacy of the binutils patch
(https://sourceware.org/bugzilla/show_bug.cgi?id=16177#c9) the resulting
binary seems to run without issue on the target platform. Jessica's
patch there caused ld to fail linking some programs. Nick's proposed
patch has worked well in my testing so far (a Haskell project of some
small complexity cross compiled with musl to armv7).
This adds a warning to the top of each “boot” package that reads:
Note: this package is used for bootstrapping fetchurl, and thus cannot
use fetchpatch! All mutable patches (generated by GitHub or cgit) that
are needed here should be included directly in Nixpkgs as files.
This makes it clear to maintainer that they may need to treat this
package a little differently than others. Importantly, we can’t use
fetchpatch here due to using <nix/fetchurl.nix>. To avoid having stale
hashes, we need to include patches that are subject to changing
overtime (for instance, gitweb’s patches contain a version number at
the bottom).
Pythons find_library is broken with binutils 2.34, and numpy could not import libraries because of not properly aligned ELF's.
This is the second time binutils 2.34 got reverted. Next time, we should have a dedicated Hydra job for it.
This reverts commit 629fa8a2d4, reversing
changes made to 4ddd080d19.
Some packages don’t work correctly with pie. Here I disable it for:
- busybox
- linux kernel
- kexectools
I also get rid of the Musl conditional for disabling pie in GCC and
Binutils. Some day we might want to enable PIE without Musl and it
will be useful to have the *just* work with our compiler and linkers.
