Upstream binutils is missing sensible defaults for a few flags
(notably linker personality) when cross-compiling to
mips64el-*-*abi64.
Most of the time this isn't an issue because packages that invoke the
linker directly detect the flags from gcc's behavior (for example,
libtool does this) and gcc has good code for detecting the right
defaults. However some do not; notably nix, itself lacks this.
Presumably Debian is working on upstreaming this, and has more clout
than we do. I propose we carry their patch in the meantime. The
patch is conditioned on stdenv.targetPlatform.isMips64n64 in order to
avoid mass-rebuilds.
Closes#164835.
Otherwise the patch application fails as:
applying patch /nix/store/y0l0144l12q7jpq4jv735shgxv8ygxwh-build-components-separately.patch
1 out of 3 hunks FAILED -- saving rejects to file opcodes/Makefile.am.rej
1 out of 2 hunks FAILED -- saving rejects to file opcodes/configure.ac.rej
1 out of 2 hunks FAILED -- saving rejects to file opcodes/configure.ac.rej
ld.gold is “A new, faster, ELF only linker”. Thus we only should pass
the configure flag --with-gold if our target platform will actually
support gold (in which case binutil's configure script silently
disables it).
With this change, not only will configureFlags represent the actual
configuration more closely, but we can also expose if the binutils
derivation contains ld.gold via a passthru attr. Specifically this
means that:
nix-repl> pkgsCross.mingwW64.stdenv.cc.bintools.bintools.hasGold
false
The intended way to use this is to check
`stdenv.cc.bintools.bintools or false` which returns accurate results
regardless of the actual linker derivation.
TODO: maybe also add hasGold to binutils wrapper as it also symlinks
ld.gold in?
Backport patch from 2.36 so that gold can succeed in linking programs without complaining
unknown program property type 0xc0008002 in .note.gnu.property section
Should fix: https://github.com/NixOS/nixpkgs/issues/134190
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.
