Docker-related cross-compilation fixes

[nspin]

Motivation for this change

Fixes cross-compilation for:

• cni
• tini
• containerd
• docker

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)
• Ensured that relevant documentation is up to date
• Fits CONTRIBUTING.md.

Notify maintainers

cc @

[nspin]

In the case of cross-compilation, go refers to the host derivation, but we need the build derivation. .nativeDrv is only present when we're cross-compiling (this is the result of an optimization in splice.nix).

There are many similar cases in nixpkgs where a native dependency is meant to be interpolated into a string. For example, grep for remove-references-to -t ${go}. As in the case above, this does not work when cross-compiling.

There are no explicit references to .nativeDrv like this in nixpkgs. Such explicit references don't feel like the right solution here, especially considering the fact that the .nativeDrv attribute is unstable, and will someday be renamed to pkgBuildHost. Should we add library functions to wrap explicit access?

[nspin]

Related: #49526 (comment) and #68895

[matthewbauer]

I think buildPackages.go would be better here? /cc @Ericson2314

[nspin]

Especially for removing references, the go interpolated into that string must match the one used as a nativeBuildInput. So, buildPackages.go would have to replace each instance of go in that file. The drawback of this approach is that go becomes harder to override for this package.

[Ericson2314]

Yes that is a the drawback, but splicing is evil in using things like builtins.tryEval and still falling over itself when the packages are too different. It's better to use buildInputs.go, I'm afraid. If you really want, you could do goForBuild = buildPackages.go in the override list or something and use that.

[nspin]

I agree that this is the best solution in sight right now.

[nspin]

Same issue with .nativeDrv here.

[stale]

Thank you for your contributions.
This has been automatically marked as stale because it has had no activity for 180 days.
If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity.
Here are suggestions that might help resolve this more quickly:

1. Search for maintainers and people that previously touched the
   related code and @ mention them in a comment.
2. Ask on the NixOS Discourse. 3. Ask on the #nixos channel on
   irc.freenode.net.

[nspin]

(In response to the automatic marking of this PR as stale)

I'm still interested in how cross compilations issues like this one, brought about as a side effect of splicing, are best addressed.

[Mic92]

Sorry for letting this getting stalled. If you could rebase this. I will have a look.

[betaboon]

i ran into this issue today and got it building with the help of @Mic92.
he advised to convert the package to use buildGoPackage.

this is the diff i ended up with: https://gist.github.com/betaboon/b0f7d8311297fe6ae6e751783c876272

[Mic92]

@betaboon can you make this a PR?

[betaboon]

@nspin do you want to pick this back up and get it merged or should i take over?

i think #50925 is still blocking docker from successfully cross-compiling. i ended up overriding it to btrfs-progs = null; for docker, which deactivates the btrfs-support thus the cross-compile succeeds.

cc @Mic92

[nspin]

@betaboon If you've got a patch ready, go for it! I'm also happy to finish up if you'd prefer that.

However, I noticed this added line in your gist:

find $out/libexec -type f -exec remove-references-to -t ${buildPackages.go} '{}' +

This line faces the same issue that I tried to address in this PR. If buildGoPackages is overridden (to, for example, override the Go version), buildPackages.go no longer refers to the intended derivation.

This isn't a big deal in itself, but while cross-compilation Nixpkgs I found a number of similar instances. In this case, this problem doesn't get in the way of the derivation's functionality, it just may result in a bloated closure. #68900 (comment) suggests a good immediate solution for cases where this sort of issue is more of a problem.

[betaboon]

@nspin I'm just preparing a PR and building for armv7l here to see if it works fine.

on the remove references-to-issue: @Mic92 suggested adding find $out/libexec -type f -exec ${removeExpr removeReferences} '{}' + || true here

[nspin]

Great! It appears that the go argument of go-packages/generic.nix is always passed explicitly with a value of the form buildPackages.go_*, so that should indeed work.

[betaboon]

@nspin i just pushed the changes to a new pr #68900

but this is still blocked by #50925 (on armv7l)