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.
When cross compiling, buildPackages.cargo uses a rustc that can build
for both the build and host platforms. This was not true of
buildPackages.clippy, so it was not possible to use clippy for a cross
target. Now it is.
I've modified clippy.nix to use rustc from rustPlatform, so we only
have to add a single override in default.nix.
If RUSTFLAGS is set in the environment, Cargo will ignore rustflags
settings in its TOML configuration. So setting RUSTFLAGS=-g (like
separateDebugInfo does) to generate debug info breaks
dynamically-linked Rust packages on musl. This breakage is visible
for any packages that call into C dynamic libraries. If the binary is
linked directly to a C dynamic library, it will fail to build, and if
it depends on a Rust library which links a C dynamic library, it will
segfault at runtime when it tries to call a function from the C
library. I noticed this because pkgsMusl.crosvm is broken for this
reason, since it sets separateDebugInfo = true.
It shouldn't be possible to end up with broken binaries just by using
RUSTFLAGS to do something innocuous like enable debug info, so I think
that, even though we liked the approach of modiyfing .cargo/config
better at the time, it's become clear that it's too brittle, and we
should bite the bullet and patch the compiler instead when targetting
musl. It does not appear to be necessary to modify the compiler at
all when cross-compiling /from/ dynamically-linked Musl to another
target, so I'm only checking whether the target system is
dynamically-linked Musl when deciding whether to make the modification
to the compiler.
This reverts commit c2eaaae50d
("cargoSetupHook: pass host config flags"), and implements the
compiler patching approach instead.
We previously disabled this based on a now-closed issue from 2015 [0].
I think enough time has passed that we can give it a shot again, given
that the in the worst case scenario we revert, and in the best case
scenario we get a performance boost.
[0]: https://github.com/rust-lang/rust/issues/30181
As of Rust 1.67.0, the cargo-clippy binary now relies on the rustc_private
libraries [0], so let's do the RPATH fixup to it too.
I've also added a comment to explain the RPATH situation, as it took me
a bit to figure out.
[0]: https://github.com/rust-lang/rust-clippy/pull/9541
ripgrep is a very popular grep replacement (similar to fd and find)
and wezterm is a popular terminal emulator which has a big codebase with
lots of features tested (it also broke in the past multiple times on
rustc upgrades.).
