This commit adds the machinery required to get our `rustc.nix` to
work using upstream's git repository, directly, without them waving
dead chickens over it and performing whatever other occult rituals
are involved in creating a release tarball.
No chickens, live or dead, were harmed in the creation of this
commit.
The hash for pytensor is not correct, but that's also the case in
master, so a merge commit isn't the place to fix it.
Conflicts:
pkgs/development/python-modules/faadelays/default.nix
pkgs/development/python-modules/pytensor/default.nix
pkgs/tools/admin/rset/default.nix
When cross-compiling a rust package, all we need is the std library compiled
for the target. This uses the final stage compiler which was built for Build
and then uses that as a stage0 compiler for target std library.
It also copies the rust binary from pkgsBuildBuild so that it find the new
lib/rustlib directory.
We also need to create a cargo wrapper which will use the "new" rust compiler
Also makes sure man pages and doc pages are propagated
Co-authored-by: Alyssa Ross <hi@alyssa.is>
Co-authored-by: Sandro <sandro.jaeckel@gmail.com>
Co-authored-by: Rick van Schijndel <Mindavi@users.noreply.github.com>
Recent changes to `cargo-auditable-cargo-wrapper` and `librsvg`
caused it to ignore the user's decision to opt out of `cargo-audit`
functionality, partially because `librsvg` does not use
`buildRustPackage`.
This commit restores the single-point-of-opt-out from this mis-named
functionality: `cargo-auditable.meta.broken`.
Co-authored-by: figsoda <figsoda@pm.me>
An attempt to remove it was made in #106886, but there was a build
failure. Since that failure no longer occurs, remove it now.
Based on thefloweringash/nixpkgs@1904236648.
armv6l-linux was incorrectly added to the list of platforms without host
tools in #227987. arm-unknown-linux-gnueabihf is present in the list of
Tier 2 targets with host tools, and this target corresponds to our
armv6l-linux platform.
Reading this [rust-issue] it seems that we have to link against
rustc_driver. The [clippy.nix] expression already does something similar
Of the 4 executables found in the result of building rustfmt only
rustfmt and git-rustfmt needed to be linked. The other worked without
linking to rustc_driver.
[rust-issue]: https://github.com/rust-lang/rust/pull/105609
[clippy.nix]: c8cf570dae/pkgs/development/compilers/rust/clippy.nix (L27-L36)
It is almost never correct to use these attributes, because they don't
work correctly with splicing. Compare:
% nix repl -f . --argstr crossSystem aarch64-linux
Welcome to Nix 2.10.3. Type :? for help.
Loading installable ''...
Added 18988 variables.
nix-repl> callPackage ({ stdenv, rustc }: (stdenv.mkDerivation { name = ""; nativeBuildInputs = [ rustc ]; }).nativeBuildInputs) {}
«derivation /nix/store/bjrkg8kcq3hvg5kb03ivb856zy91qpbk-aarch64-unknown-linux-gnu-rustc-1.69.0.drv» ]
nix-repl> callPackage ({ stdenv, rustPlatform }: (stdenv.mkDerivation { name = ""; nativeBuildInputs = [ rustPlatform.rust.rustc ]; }).nativeBuildInputs) {}
«derivation /nix/store/ra5r07j52y7akclr827r3dzxzvqnvfbl-rustc-1.69.0.drv» ]
I'm not sure this is fixable. I don't think it's worth keeping them
around considering we have top level attributes. It makes overriding
slightly more annoying, but only slightly.
I made a mistake when trying to add the target prefix to Rust cross
compilers: pkgsCross.aarch64-multiplatform.rustc ended up being called
"aarch64-unknown-linux-gnu-rustc-aarch64-unknown-linux-gnu-1.69.0",
which is a bit verbose.
With this change:
nix-repl> rustc.name
"rustc-1.69.0"
nix-repl> pkgsCross.aarch64-multiplatform.buildPackages.rustc.name
"aarch64-unknown-linux-gnu-rustc-1.69.0"
nix-repl> pkgsCross.aarch64-multiplatform.rustc.name
"rustc-aarch64-unknown-linux-gnu-1.69.0"
As intended.
Fixes: 57e73d23bb ("rustc,rustPlatform.buildRustPackage: broaden platforms")
rustc supports way more platforms than Linux and Darwin. We might not
be able to build it for every platform at the moment, but that's what
meta.broken is for.
There are other platforms that rustc can produce binaries for, but
can't run on itself, so those are listed in the defaults for
buildRustPackage.
Prior to this commit, builds of
`pkgsCross.aarch64-multiplatform.cargo` would fail due to being
unable to find `-lz` when compiling cargo's own `build.rs` for the
`buildPlatform`.
This environment variable uses the (very confusing) LLVM convention
of calling the buildPlatform "HOST".
Co-authored-by: figsoda <figsoda@pm.me>
Our `rustc.nix` adds a `--target` flag for the host when doing a
host!=target build, but neglects to add a `--target` flag for the
buildPlatform when doing a build!=(host==target) build. This commit
corrects that.
Before rustc 1.68 omitting the --target flag for the buildPlatform
did not cause any problems. As of rustc 1.68, build!=host without a
--target for the build will fail like below (with hundreds more
"cannot find std::" errors.
```
$ nix build -f . -L pkgsCross.aarch64-multiplatform.rustc
...
Copying stage1 library from stage1 (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu / aarch64-unknown-linux-gnu)
Uplifting stage1 library (x86_64-unknown-linux-gnu -> aarch64-unknown-linux-gnu)
Copying stage2 library from stage1 (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu / aarch64-unknown-linux-gnu)
Building stage2 tool rust-analyzer-proc-macro-srv (aarch64-unknown-linux-gnu)
Compiling autocfg v1.1.0
Compiling libc v0.2.135
Compiling cfg-if v1.0.0
Compiling proc-macro2 v1.0.47
Compiling quote v1.0.21
Compiling unicode-ident v1.0.5
Compiling syn v1.0.102
Compiling once_cell v1.15.0
Compiling parking_lot_core v0.9.4
Compiling serde_derive v1.0.145
Compiling hashbrown v0.12.3
Compiling scopeguard v1.1.0
Compiling smallvec v1.10.0
Compiling log v0.4.17
Compiling serde v1.0.145
Compiling rustc-hash v1.1.0
error[E0463]: can't find crate for `std`
error: cannot find macro `println` in this scope
--> /nix/tmp/nix-build-rustc-aarch64-unknown-linux-gnu-1.68.2.drv-0/rustc-1.68.2-src/vendor/libc-0.2.135/build.rs:7:5
|
7 | println!("cargo:rerun-if-changed=build.rs");
| ^^^^^^^
error: cannot find macro `println` in this scope
--> /nix/tmp/nix-build-rustc-aarch64-unknown-linux-gnu-1.68.2.drv-0/rustc-1.68.2-src/vendor/libc-0.2.135/build.rs:16:9
|
16 | println!(
| ^^^^^^^
error: cannot find macro `println` in this scope
--> /nix/tmp/nix-build-rustc-aarch64-unknown-linux-gnu-1.68.2.drv-0/rustc-1.68.2-src/vendor/libc-0.2.135/build.rs:29:13
|
29 | println!("cargo:rustc-cfg=freebsd10")
| ^^^^^^^
```
Our rustc package is not universal, because we only build std for the
host and target platforms. This means that a build graph where cross
is involved will end up with multiple rustc packages in it, so it
would be helpful to have a way to tell them apart, just like we do for
e.g. gcc.
