Outdated dependencies causing build failure on rustc ≥1.71

Question

Outdated dependencies causing build failure on rustc ≥1.71

Opened this issue a year ago · 7 comments

Hi, I wanted to package this program for my distribution and personal package repository, but when trying to build, it fails to compile due to a dependency.

System info

~ ¥ rustc -V
rustc 1.73.0-nightly (b3df56a65 2023-07-31) (gentoo)

Ebuild for colorgen-nvim

I at first thought maybe it's due to making the ebuild file wrong, so I cloned the repository locally and ran cargo build while in it, giving the same failure as through the distro package manager:

~/Documents/Git/Dissociated/colorgen-nvim ¥ cargo build
   Compiling proc-macro2 v1.0.56
   Compiling io-lifetimes v1.0.10
   Compiling indexmap v1.9.3
   Compiling thiserror v1.0.40
   Compiling minimal-lexical v0.2.1
   Compiling once_cell v1.17.1
   Compiling bitflags v2.2.1
   Compiling rustix v0.37.18
error[E0635]: unknown feature `proc_macro_span_shrink`
  --> /home/kir68k/.cargo/registry/src/index.crates.io-6f17d22bba15001f/proc-macro2-1.0.56/src/lib.rs:92:30
   |
92 |     feature(proc_macro_span, proc_macro_span_shrink)
   |                              ^^^^^^^^^^^^^^^^^^^^^^

For more information about this error, try `rustc --explain E0635`.
error: could not compile `proc-macro2` (lib) due to previous error
warning: build failed, waiting for other jobs to finish...
Exception: cargo exited with 101
[tty 68]:1:1: cargo build

I noticed a few of the dependencies in Cargo.lock are outdated, so I ran cargo update.
After cargo update, I ran cargo build which could build the project correctly:

   [...]
   Compiling toml v0.7.6
   Compiling clap v4.3.19
   Compiling colorgen-nvim v0.3.0 (/home/kir68k/Documents/Git/Dissociated/colorgen-nvim)
    Finished dev [unoptimized + debuginfo] target(s) in 16.15s

Doing git reset --hard HEAD and building again causes the failure as expected.

Since my primary rustc is built from the most recent git commit, hence v1.73, I installed rust-bin alongside to test if it works on v1.71, the most recent version in my distro's repositories, and the latest release on GitHub.

~/Documents/Git/Dissociated/colorgen-nvim ¥ cargo-bin-1.71.0 build
   Compiling quote v1.0.26
   Compiling proc-macro2 v1.0.56
   Compiling serde v1.0.160
   Compiling io-lifetimes v1.0.10
   Compiling memchr v2.5.0
   Compiling colorchoice v1.0.0
   Compiling indexmap v1.9.3
   Compiling anstyle-query v1.0.0
   Compiling anstyle v1.0.0
   Compiling strsim v0.10.0
   Compiling thiserror v1.0.40
   Compiling clap_lex v0.4.1
error[E0635]: unknown feature `proc_macro_span_shrink`
  --> /home/kir68k/.cargo/registry/src/index.crates.io-6f17d22bba15001f/proc-macro2-1.0.56/src/lib.rs:92:30
   |
92 |     feature(proc_macro_span, proc_macro_span_shrink)
   |                              ^^^^^^^^^^^^^^^^^^^^^^

   Compiling rustix v0.37.18
For more information about this error, try `rustc --explain E0635`.
error: could not compile `proc-macro2` (lib) due to previous error
warning: build failed, waiting for other jobs to finish...
Exception: cargo-bin-1.71.0 exited with 101
[tty 106]:1:1: cargo-bin-1.71.0 build

I also tried rustc v1.70 through nix shell nixpkgs#{rustc,cargo}, and on that version it builds fine, so this is an issue starting on v1.71, fixed by bumping proc-macro2 to v1.0.66.

Answer 1 · 2023-08-04T06:29:49.000Z

Running cargo update and generating a Cargo.lock patch^*, which is passed to the package manager, fixes the issue and the program works as expected with the provided test toml file.

In the patch, work/colorgen-nvim-9999/Cargo.lock is used as a path, that's specific to my package manager's patching process, and normally it would be something like a/Cargo.lock.

Answer 2 · 2023-08-04T20:16:05.000Z

I tried to recreate this and get the same compile error when using the
nightly build provided by rustup (rustc 1.73.0-nightly (474709a9a 2023-08-03)),
while compiling fine on the latest stable release (rustc 1.71.1 (eb26296b5 2023-08-03)).

Which is honestly not completely surprising as nightly is explicitly
unstable and there are no guaranties from the rust project that the
compiler works completely as expected.

While I do agree that the dependencies should be updated, (especially clap 3 to clap 4,)
I think it might be best for you to use at most the latest beta version
of rustc, if you expect it to consistently compile.

Also it might be a good idea to use rustup to manage your different rust
versions, that way you can specify the version you want to use with
cargo +nightly build, you can even link the rustc version your package manager provides into rustup.

Answer 3 · 2023-08-04T21:04:01.000Z

Oh, I thought 1.71 would be stable, with the main website stating 1.71.1 to be the latest stable? Sorry, I'm not too familiar with Rust yet.

To clarify a bit, I am alright with build failures when using the 1.73 git build, that's expected. That is why I installed 1.71 alongside, and tried 1.70 in a Nix env, for comparison.

When running rustc-bin-1.71.0 --version I get rustc 1.71.0 (8ede3aae2 2023-07-12, it doesn't say nightly like my primary, git master built one.

So is the bin-1.71.0 one not nightly? And if so, I find it weird 1.71.0 doesn't compile, but 1.71.1 for you does.

Answer 4 · 2023-08-05T08:45:55.000Z

1.71 is definitely stable. 1.71.1 is too, but is a patch version that
was published because of security concerns that couldn't wait the normal six
week development cycle. (See this article for more details.)

I tried running cargo with both rustc 1.71.0 (8ede3aae2 2023-07-12)
(the same stable version you used) and rustc 1.71.1 (eb26296b5 2023-08-03)
and both compile fine.

My only guess why that could be is that your cargo version for 1.71.0
doesn't use the correct version of rustc.
(cargo is basically only calling rustc with a few arguments for compilation.)
You can test by running cargo check --verbose to get the absolute path
of the rustc cargo uses.

Answer 5 · 2023-08-05T08:59:35.000Z

~~I think that's it actually. Using cargo-bin-1.71.0 check -vv gives something odd:~~

LD_LIBRARY_PATH='/home/kir68k/Documents/Git/Dissociated/colorgen-nvim/target/debug/deps:/usr/lib/rust/9999/lib' rustc

So it uses the 9999 (live/git version) lib directory for Rust, and doesn't call rustc-bin-1.71.0, actually compiling using the nightly one. Seems like this is more of a bug with the -bin package of Rust I tried to use¹. Thanks for that command.

I still think updating depends will help for compiling in the future, though, if 1.73 releases as stable and this error will appear, provided that version doesn't get changes making it go away.

Due to that I'm not sure if this should be closed for now.

EDIT
¹ This was not a bug, I entirely forgot to run eselect rust set rust-bin-1.71.0, which sets the correct LD_LIBRARY_PATH when running cargo... It was set to the nightly one I usually use.

After setting that, the project compiles fine using 1.71.0. Apologies for any confusion :D

Answer 6 · 2023-08-05T09:54:01.000Z

No worries.
I agree that updating dependencies is definitely a good idea, but
I don't really worry about not doing it will break something in the
future.

Rust's stability guaranties say that something built in Rust 1.* will
always continue to compile. There is even a program called crater that
is run on every stable release that compiles every single crate on
https://www.crates.io to make sure this guarantee holds.

Answer 7 · 2023-08-05T10:00:03.000Z

Didn't know of that, I retract my statement about future versions then.
The crater project you've mentioned reminds me of Stackage for Haskell, which I'm more familiar with.

Anyhow, have a nice day, I think this can be closed after dependencies are updated.