Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enable cross compilation on buildGoPackage #63603

Merged

Conversation

dingxiangfei2009
Copy link
Contributor

@dingxiangfei2009 dingxiangfei2009 commented Jun 21, 2019

Motivation for this change

Current buildGoPackage family of functors does not set necessary cross-compilation flags to go calls. This PR will enable true cross-compilation by inheriting the necessary flags from the go derivation, such as GOARCH, GOOS, CC and CXX.

Things done
  • Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
  • Built on platform(s)
    • NixOS
    • macOS
    • other Linux distributions
  • Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
  • Tested compilation of all pkgs that depend on this change using nix-shell -p nix-review --run "nix-review wip"
  • Tested execution of all binary files (usually in ./result/bin/)
  • Determined the impact on package closure size (by running nix path-info -S before and after)
  • Assured whether relevant documentation is up to date
  • Fits CONTRIBUTING.md.

@dingxiangfei2009 dingxiangfei2009 force-pushed the cross-compiling-buildGoPackage branch 4 times, most recently from 046d14d to 07a3d7d Compare June 21, 2019 08:28
@nixos-discourse
Copy link

This pull request has been mentioned on Nix community. There might be relevant details there:

https://discourse.nixos.org/t/kubernetes-on-arm-raspberry-pi/3182/2

GOHOSTARCH = go.GOHOSTARCH or null;
GOHOSTOS = go.GOHOSTOS or null;
CC_FOR_TARGET = go.CC_FOR_TARGET or null;
CXX_FOR_TARGET = go.CXX_FOR_TARGET or null;
Copy link
Member

@Mic92 Mic92 Jun 21, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does the build use CC_FOR_TARGET or CXX_FOR_TARGET in this case at all or is it just a helper for $CC below?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah I highly doubt you want the actual CC_FOR_TARGET, which is only used for building compilers.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, the names are totally overloaded and I am using these as a helper for setting $CC below like @Mic92 said.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Specifying it here, makes it an environment variable in the build, which is not needed.

@@ -130,7 +137,7 @@ let
echo "$d" | grep -q "\(/_\|examples\|Godeps\)" && return 0
[ -n "$excludedPackages" ] && echo "$d" | grep -q "$excludedPackages" && return 0
local OUT
if ! OUT="$(go $cmd $buildFlags "''${buildFlagsArray[@]}" -v -p $NIX_BUILD_CORES $d 2>&1)"; then
if ! OUT="$(CC=$CC_FOR_TARGET CXX=$CXX_FOR_TARGET go $cmd $buildFlags "''${buildFlagsArray[@]}" -v -p $NIX_BUILD_CORES $d 2>&1)"; then
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if stdenv.buildPlatform != stdenv.targetPlatform then CC_FOR_TARGET becomes null. This would lead to CC not being set at all. Should $CC not have the correct value anyway?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

True. I will add checking for this corner case.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also check how this is different from the current value $CC.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Mic92 I notice the following. Take pkgsCross.aarch64-multiplatform.ws as an example. If you inspect pkgsCross.aarch64-multiplatform.ws.stdenv.hostPlatform.config, you get x86_64-unknown-linux-gnu on a Linux machine. This platform triple looks wrong. The reason could be cause buildGoPackage actually uses go.stdenv.mkDerivation instead of just stdenv.

@Mic92
Copy link
Member

Mic92 commented Jun 21, 2019

cc @matthewbauer @Ericson2314

@Mic92
Copy link
Member

Mic92 commented Jun 21, 2019

For reference here is the documentation for all environment variables used by the go compiler: https://golang.org/doc/install/source#environment

@Mic92
Copy link
Member

Mic92 commented Jun 21, 2019

This seems to fixed the build of pkgsCross.aarch64-multiplatform.ws which did not build before because of cgo.

@dingxiangfei2009 dingxiangfei2009 force-pushed the cross-compiling-buildGoPackage branch 2 times, most recently from 3bd14e8 to b82df87 Compare June 25, 2019 06:36
Copy link
Member

@Mic92 Mic92 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks much better now

@dingxiangfei2009
Copy link
Contributor Author

@Mic92 A merge conflict was just resolved

@dingxiangfei2009
Copy link
Contributor Author

@Mic92 Since this PR induces a mass rebuild, is it a good idea to target staging branch instead?

@Mic92
Copy link
Member

Mic92 commented Jul 9, 2019

Should be fine on master. go packages can be rebuild fast.

@Ericson2314 Ericson2314 merged commit 5e84f73 into NixOS:master Jul 11, 2019
@dingxiangfei2009 dingxiangfei2009 deleted the cross-compiling-buildGoPackage branch July 12, 2019 15:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants