binutils-unwrapped, gcc, gdb: force targetPrefix if cross compiling #119625
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
ac3de59 to
cccfca6
Compare
|
For reference, this is the new failure when building |
Ericson2314
reviewed
Apr 16, 2021
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.
cccfca6 to
ca9be05
Compare
363c771 to
9a01a6e
Compare
Don't rely on gcc detecting from the passed platforms which prefix to use, but always specify the prefix nixpkgs expects (or doesn't). This allows us to work around problems where the configure script would add prefix where nixpkgs doesn't expect one (if `--target` was specified, but the same as `--host`) or doesn't add one if nixpkgs expects one (if `--target` and `--host` are the same, but we are actually cross compiling, but the relevant parts of the platform are not encoded into the platform config. See also ca9be05.
9a01a6e to
9c396b6
Compare
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 ca9be05.
9c396b6 to
e75c535
Compare
|
I built |
|
|
10 tasks
|
Great! I've also checked: All |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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):
Still not working is pkgsCross.gnu64.
Motivation for this change
Things done
sandboxinnix.confon non-NixOS linux)nix-shell -p nixpkgs-review --run "nixpkgs-review wip"./result/bin/)nix path-info -Sbefore and after)