python3Packages.cryptography: fix invalid platform for Rust on cross-…

[Cynerd]

Description of changes

The Rust library was being built for the build platform and not for the host platform when cross-compiling. This sets build so it builds it for the correct platform.

The issue was reported and investigated in #205807

I was looking also into other packages that use setuptools-rust, and it seems that the same modifications are required there as well.

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 23.05 Release Notes (or backporting 22.11 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
  • (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes
• Fits CONTRIBUTING.md.

[Artturin]

i recommend adding a setup hook to setuptools-rust that does these

  CARGO_BUILD_TARGET_TARGET = "${rust.toRustTargetSpec targetPackages.stdenv.hostPlatform}";
  PYO3_CROSS_LIB_DIR_TARGET = "${targetPackages.python}/lib/${targetPackages.python.libPrefix}";
  CARGO_LINKER_VAR = "CARGO_TARGET_${lib.toUpper (builtins.replaceStrings ["-"] ["_"] (rust.toRustTarget targetPackages.stdenv.hostPlatform))}_LINKER"
	TARGET_LINKER = "${targetPackages.stdenv.cc}/bin/${targetPackages.stdenv.cc.targetPrefix}cc";

add the above to the setuptools-rust and a setup hook that exports them

export CARGO_BUILD_TARGET_TARGET=@CARGO_BUILD_TARGET@
export PYO3_CROSS_LIB_DIR_TARGET=@PYO3_CROSS_LIB_DIR@
export @CARGO_LINKER_VAR@=@TARGET_LINKER@

[SuperSandro2000]

Suggested change

	CARGO_BUILD_TARGET = "${rust.toRustTargetSpec stdenv.hostPlatform}";
	PYO3_CROSS_LIB_DIR = "${python}/lib/${python.libPrefix}";
	"CARGO_TARGET_${lib.toUpper (builtins.replaceStrings ["-"] ["_"] (rust.toRustTarget stdenv.hostPlatform))}_LINKER" =
	"${stdenv.cc}/bin/${stdenv.cc.targetPrefix}cc";
	CARGO_BUILD_TARGET = rust.toRustTargetSpec stdenv.hostPlatform;
	PYO3_CROSS_LIB_DIR = "${python}/lib/${python.libPrefix}";
	"CARGO_TARGET_${lib.toUpper (builtins.replaceStrings ["-"] ["_"] (rust.toRustTarget stdenv.hostPlatform))}_LINKER" =
	"${stdenv.cc}/bin/${stdenv.cc.targetPrefix}cc";

Are those generic variables we want to set?
If so we should move them to a setup-hook like maturin or setuptools-rust

[Cynerd]

That is the question... I took those variables from here https://github.com/PyO3/setuptools-rust/blob/main/.github/workflows/ci.yml#L270 and here PyO3/setuptools-rust#294 (comment). The CARGO_BUILD_TARGET and PYO3_CROSS_LIB_DIR seem reasonable, but I am not sure about CARGO_TARGET_*. It is kind of weird to have to specify the linker. No other package except of crosvm has to do this (that is where I took it from anyway).

[winterqt]

It is kind of weird to have to specify the linker.

Especially weird given that we already do this:

nixpkgs/pkgs/build-support/rust/hooks/default.nix

Lines 98 to 110 in 06542b2

	cargoConfig = ''
	[host]
	"linker" = "${ccForBuild}"
	"rustflags" = [ "-C", "target-feature=${if stdenv.buildPlatform.isStatic then "+" else "-"}crt-static" ]
	[target."${shortTarget}"]
	"linker" = "${ccForHost}"
	"rustflags" = [ "-C", "target-feature=${if stdenv.hostPlatform.isStatic then "+" else "-"}crt-static" ]
	[unstable]
	host-config = true
	target-applies-to-host = true
	'';

[SuperSandro2000]

Can we assert/check in a setup hook this somewhere to make sure this is correct?

[Cynerd]

Or should this be propagated inputs for setuptools-rust?

[cole-h]

@ofborg eval

[Cynerd]

Superseded by #212795.