ICE on building vte ("Failed to get crate data for crate6")

[wucke13]

Reproduce

cd /tmp
cargo init bad_apple
cd bad_apple
echo 'skim = "*"' >> Cargo.toml
cargo build

Meta

rustc --version --verbose:

rustc 1.52.1 (9bc8c42bb 2021-05-09)

Error output

     Running `rustc --crate-name vte --edition=2018 /home/wucke13/.cargo/registry/src/github.com-1ecc6299db9ec823/vte-0.9.0/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts --crate-type lib --emit=dep-info,metadata,link -C embed-bitcode=no -C debuginfo=2 --cfg 'feature="arrayvec"' --cfg 'feature="default"' --cfg 'feature="no_std"' -C metadata=6fda4d894e80b3da -C extra-filename=-6fda4d894e80b3da --out-dir /tmp/bad_apple/target/debug/deps -L dependency=/tmp/bad_apple/target/debug/deps --extern arrayvec=/tmp/bad_apple/target/debug/deps/libarrayvec-4f1fbeb39da0cb4b.rmeta --extern utf8parse=/tmp/bad_apple/target/debug/deps/libutf8parse-edc683679d7c9ca6.rmeta --extern vte_generate_state_changes=/tmp/bad_apple/target/debug/deps/libvte_generate_state_changes-8374f0a98be54983.so --cap-lints allow`
thread 'rustc' panicked at 'Failed to get crate data for crate6', compiler/rustc_metadata/src/creader.rs:136:32
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

error: internal compiler error: unexpected panic

note: the compiler unexpectedly panicked. this is a bug.

note: we would appreciate a bug report: https://github.com/rust-lang/rust/issues/new?labels=C-bug%2C+I-ICE%2C+T-compiler&template=ice.md

note: rustc 1.52.1 (9bc8c42bb 2021-05-09) running on x86_64-unknown-linux-gnu

note: compiler flags: -C embed-bitcode=no -C debuginfo=2 --crate-type lib

note: some of the compiler flags provided by cargo are hidden

query stack during panic:
end of query stack
error: could not compile `vte`

Caused by:
  process didn't exit successfully: `rustc --crate-name vte --edition=2018 /home/wucke13/.cargo/registry/src/github.com-1ecc6299db9ec823/vte-0.9.0/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts --crate-type lib --emit=dep-info,metadata,link -C embed-bitcode=no -C debuginfo=2 --cfg 'feature="arrayvec"' --cfg 'feature="default"' --cfg 'feature="no_std"' -C metadata=6fda4d894e80b3da -C extra-filename=-6fda4d894e80b3da --out-dir /tmp/bad_apple/target/debug/deps -L dependency=/tmp/bad_apple/target/debug/deps --extern arrayvec=/tmp/bad_apple/target/debug/deps/libarrayvec-4f1fbeb39da0cb4b.rmeta --extern utf8parse=/tmp/bad_apple/target/debug/deps/libutf8parse-edc683679d7c9ca6.rmeta --extern vte_generate_state_changes=/tmp/bad_apple/target/debug/deps/libvte_generate_state_changes-8374f0a98be54983.so --cap-lints allow` (exit code: 101)
warning: build failed, waiting for other jobs to finish...
error: build failed

Backtrace

   0: rust_begin_unwind
             at /rustc/9bc8c42bb2f19e745a63f3445f1ac248fb015e53/library/std/src/panicking.rs:493:5
   1: std::panicking::begin_panic_fmt
             at /rustc/9bc8c42bb2f19e745a63f3445f1ac248fb015e53/library/std/src/panicking.rs:435:5
   2: rustc_metadata::creader::CrateLoader::maybe_resolve_crate
   3: rustc_metadata::creader::CrateLoader::maybe_process_path_extern
   4: rustc_resolve::Resolver::extern_prelude_get
   5: rustc_resolve::macros::<impl rustc_resolve::Resolver>::early_resolve_ident_in_lexical_scope
   6: rustc_resolve::Resolver::resolve_path_with_ribs::{{closure}}
   7: rustc_resolve::Resolver::resolve_path_with_ribs
   8: rustc_resolve::imports::ImportResolver::resolve_imports
   9: rustc_resolve::macros::<impl rustc_expand::base::ResolverExpand for rustc_resolve::Resolver>::resolve_imports
  10: rustc_expand::expand::MacroExpander::fully_expand_fragment
  11: rustc_expand::expand::MacroExpander::expand_crate
  12: rustc_session::utils::<impl rustc_session::session::Session>::time
  13: rustc_interface::passes::configure_and_expand_inner
  14: rustc_interface::passes::configure_and_expand::{{closure}}
  15: rustc_data_structures::box_region::PinnedGenerator<I,A,R>::new
  16: rustc_interface::passes::configure_and_expand
  17: rustc_interface::queries::Queries::expansion
  18: rustc_interface::queries::<impl rustc_interface::interface::Compiler>::enter
  19: rustc_span::with_source_map
  20: rustc_interface::interface::create_compiler_and_run
  21: scoped_tls::ScopedKey<T>::set
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

error: internal compiler error: unexpected panic

note: the compiler unexpectedly panicked. this is a bug.

note: we would appreciate a bug report: https://github.com/rust-lang/rust/issues/new?labels=C-bug%2C+I-ICE%2C+T-compiler&template=ice.md

note: rustc 1.52.1 (9bc8c42bb 2021-05-09) running on x86_64-unknown-linux-gnu

note: compiler flags: -C embed-bitcode=no -C debuginfo=2 --crate-type lib

note: some of the compiler flags provided by cargo are hidden

query stack during panic:
end of query stack
   0: rust_begin_unwind
             at /rustc/9bc8c42bb2f19e745a63f3445f1ac248fb015e53/library/std/src/panicking.rs:493:5
   1: std::panicking::begin_panic_fmt
             at /rustc/9bc8c42bb2f19e745a63f3445f1ac248fb015e53/library/std/src/panicking.rs:435:5
   2: rustc_metadata::creader::CrateLoader::maybe_resolve_crate
   3: rustc_metadata::creader::CrateLoader::maybe_process_path_extern
   4: rustc_resolve::Resolver::extern_prelude_get
   5: rustc_resolve::macros::<impl rustc_resolve::Resolver>::early_resolve_ident_in_lexical_scope
   6: rustc_resolve::Resolver::resolve_path_with_ribs::{{closure}}
   7: rustc_resolve::Resolver::resolve_path_with_ribs
   8: rustc_resolve::imports::ImportResolver::resolve_imports
   9: rustc_resolve::macros::<impl rustc_expand::base::ResolverExpand for rustc_resolve::Resolver>::resolve_imports
  10: rustc_expand::expand::MacroExpander::fully_expand_fragment
  11: rustc_expand::expand::MacroExpander::expand_crate
  12: rustc_session::utils::<impl rustc_session::session::Session>::time
  13: rustc_interface::passes::configure_and_expand_inner
  14: rustc_interface::passes::configure_and_expand::{{closure}}
  15: rustc_data_structures::box_region::PinnedGenerator<I,A,R>::new
  16: rustc_interface::passes::configure_and_expand
  17: rustc_interface::queries::Queries::expansion
  18: rustc_interface::queries::<impl rustc_interface::interface::Compiler>::enter
  19: rustc_span::with_source_map
  20: rustc_interface::interface::create_compiler_and_run
  21: scoped_tls::ScopedKey<T>::set
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

error: internal compiler error: unexpected panic

error: could not compile `vte`

Caused by:
  process didn't exit successfully: `rustc --crate-name vte --edition=2018 /home/wucke13/.cargo/registry/src/github.com-1ecc6299db9ec823/vte-0.9.0/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts --crate-type lib --emit=dep-info,metadata,link -C embed-bitcode=no -C debuginfo=2 --cfg 'feature="arrayvec"' --cfg 'feature="default"' --cfg 'feature="no_std"' -C metadata=6fda4d894e80b3da -C extra-filename=-6fda4d894e80b3da --out-dir /tmp/bad_apple/target/debug/deps -L dependency=/tmp/bad_apple/target/debug/deps --extern arrayvec=/tmp/bad_apple/target/debug/deps/libarrayvec-4f1fbeb39da0cb4b.rmeta --extern utf8parse=/tmp/bad_apple/target/debug/deps/libutf8parse-edc683679d7c9ca6.rmeta --extern vte_generate_state_changes=/tmp/bad_apple/target/debug/deps/libvte_generate_state_changes-8374f0a98be54983.so --cap-lints allow` (exit code: 101)
warning: build failed, waiting for other jobs to finish...
note: the compiler unexpectedly panicked. this is a bug.

note: we would appreciate a bug report: https://github.com/rust-lang/rust/issues/new?labels=C-bug%2C+I-ICE%2C+T-compiler&template=ice.md

note: rustc 1.52.1 (9bc8c42bb 2021-05-09) running on x86_64-unknown-linux-gnu

note: compiler flags: -C prefer-dynamic -C embed-bitcode=no -C debuginfo=2 --crate-type proc-macro

note: some of the compiler flags provided by cargo are hidden

query stack during panic:
end of query stack
error: build failed

[ackxolotl]

Cannot confirm. Given example built just fine on my system with stable and nightly:

rustc 1.52.1 (9bc8c42bb 2021-05-09)
binary: rustc
commit-hash: 9bc8c42bb2f19e745a63f3445f1ac248fb015e53
commit-date: 2021-05-09
host: x86_64-unknown-linux-gnu
release: 1.52.1
LLVM version: 12.0.0

rustc 1.54.0-nightly (6d395a1c2 2021-05-13)
binary: rustc
commit-hash: 6d395a1c2946c79966490f5b1e6e619d3a713e6b
commit-date: 2021-05-13
host: x86_64-unknown-linux-gnu
release: 1.54.0-nightly
LLVM version: 12.0.1

[wucke13]

Hmmh. I tried building on beta (rustc 1.53.0-beta.2 (4bac69dd2 2021-05-07)) too, now. Interestingly I get (a different) error on the same crate, vte. This might be related to my system libraries, which could be an explanation for the "cannot confirm". I'm running this on NixOS 20.09, with a local cargo which was installed through a system provided rustup.

So my guess here is: current stable crashes undesirably if the systems libc is incompatible, beta yields a better error. Shall I close this?

     Running `rustc --crate-name vte --edition=2018 /home/wucke13/.cargo/registry/src/github.com-1ecc6299db9ec823/vte-0.9.0/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts --crate-type lib --emit=dep-info,metadata,link -C embed-bitcode=no -C debuginfo=2 --cfg 'feature="arrayvec"' --cfg 'feature="default"' --cfg 'feature="no_std"' -C metadata=cada7e2728fb1dfa -C extra-filename=-cada7e2728fb1dfa --out-dir /tmp/bad_apple/target/debug/deps -L dependency=/tmp/bad_apple/target/debug/deps --extern arrayvec=/tmp/bad_apple/target/debug/deps/libarrayvec-01054b7e1cbbf029.rmeta --extern utf8parse=/tmp/bad_apple/target/debug/deps/libutf8parse-bf36fb811c7b133e.rmeta --extern vte_generate_state_changes=/tmp/bad_apple/target/debug/deps/libvte_generate_state_changes-c32257cda334b594.so --cap-lints allow`
error: /nix/store/0c7c96gikmzv87i7lv3vq5s1cmfjd6zf-glibc-2.31-74/lib/libc.so.6: version `GLIBC_2.32' not found (required by /tmp/bad_apple/target/debug/deps/libvte_generate_state_changes-c32257cda334b594.so)
 --> /home/wucke13/.cargo/registry/src/github.com-1ecc6299db9ec823/vte-0.9.0/src/table.rs:5:5
  |
5 | use vte_generate_state_changes::generate_state_changes;
  |     ^^^^^^^^^^^^^^^^^^^^^^^^^^

error: aborting due to previous error

error: could not compile `vte`

Caused by:
  process didn't exit successfully: `rustc --crate-name vte --edition=2018 /home/wucke13/.cargo/registry/src/github.com-1ecc6299db9ec823/vte-0.9.0/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts --crate-type lib --emit=dep-info,metadata,link -C embed-bitcode=no -C debuginfo=2 --cfg 'feature="arrayvec"' --cfg 'feature="default"' --cfg 'feature="no_std"' -C metadata=cada7e2728fb1dfa -C extra-filename=-cada7e2728fb1dfa --out-dir /tmp/bad_apple/target/debug/deps -L dependency=/tmp/bad_apple/target/debug/deps --extern arrayvec=/tmp/bad_apple/target/debug/deps/libarrayvec-01054b7e1cbbf029.rmeta --extern utf8parse=/tmp/bad_apple/target/debug/deps/libutf8parse-bf36fb811c7b133e.rmeta --extern vte_generate_state_changes=/tmp/bad_apple/target/debug/deps/libvte_generate_state_changes-c32257cda334b594.so --cap-lints allow` (exit status: 1)
warning: build failed, waiting for other jobs to finish...
error: `proc-macro` crate types currently cannot export any items other than functions tagged with `#[proc_macro]`, `#[proc_macro_derive]`, or `#[proc_macro_attribute]`
  --> /home/wucke13/.cargo/registry/src/github.com-1ecc6299db9ec823/time-macros-impl-0.1.1/src/lib.rs:84:13
   |
84 |               pub fn $name(input: proc_macro::TokenStream) -> proc_macro::TokenStream {
   |               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
...
91 | / impl_macros! {
92 | |     time: Time,
93 | |     offset: Offset,
94 | |     date: Date,
95 | | }
   | |_- in this macro invocation
   |
   = note: this error originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info)

error: /nix/store/0c7c96gikmzv87i7lv3vq5s1cmfjd6zf-glibc-2.31-74/lib/libc.so.6: version `GLIBC_2.32' not found (required by /tmp/bad_apple/target/debug/deps/libproc_macro_hack-cd384c8b6ea8a8ba.so)
  --> /home/wucke13/.cargo/registry/src/github.com-1ecc6299db9ec823/time-macros-impl-0.1.1/src/lib.rs:75:5
   |
75 | use proc_macro_hack::proc_macro_hack;
   |     ^^^^^^^^^^^^^^^

error: aborting due to 2 previous errors

error: build failed

[wucke13]

Okay, another related note: It seems to be that the current rustc releases require a GLIBC_2.32. Switching the target to x86_64-unknown-linux-musl is not sufficient to evade the problem, as procedural macros still are compiled against the system libc:

error: /nix/store/0c7c96gikmzv87i7lv3vq5s1cmfjd6zf-glibc-2.31-74/lib/libc.so.6: version `GLIBC_2.32' not found (required by /home/wucke13/documents/projects/rust/async-mavlink/target/debug/deps/libserde_derive-2ddc9d0f929c4e20.so)
   --> /home/wucke13/.cargo/registry/src/github.com-1ecc6299db9ec823/serde-1.0.123/src/lib.rs:293:1
    |
293 | extern crate serde_derive;
    | ^^^^^^^^^^^^^^^^^^^^^^^^^^

error: aborting due to previous error

error: could not compile `serde`

So essentially, the current rustc is now broken for everybody who does not have a GLIBC_2.32 available in their systems libc (unless they compile to musl and don't have any procedural macros in their transitive deps). This is unfortunate.

[dpc]

@wucke13 Probably a little off topic, but I am hitting the same issue, and wondering why is NixOS linking with incompatible glibc despite having plenty of other options under /nix/store. There must be some way to control which one is used.

[dpc]

OK. So pretty lamely, I still don't grok what's going on, but I had a gut feeling this is all some stale stuff somewhere and after doing some OS cleanup, wiping ~/.rustup and ~/.cargo reinstalling everything stuff seems to be working again. There's a reason why Nix community recommends using rust overlays, and not impure rustup package and I think we are suffering consequences of not listening. @wucke13

[wucke13]

Probably a little off topic, but I am hitting the same issue, and wondering why is NixOS linking with incompatible glibc despite having plenty of other options under /nix/store

It's not like nixos chooses to link with any particular version of glibc, rather it takes the glibc which was used when build some of the build tools, ld for example. So there is nothing clever about the process, rustc just uses $PATH to discover some build tools, and these build tools will happily propagate whichever glibc they have been built against.

There must be some way to control which one is used.

Unfortunately not, to my knowledge. It's not easily doable yet, but there is efforts on the way to someday get it working nicely IIRC.

but I had a gut feeling this is all some stale stuff somewhere and after doing some OS cleanup, wiping ~/.rustup and ~/.cargo reinstalling everything stuff seems to be working again.

And probably updating the nixpkgs at some point, where the new nixpkgs came with a newer version of glibc?

There's a reason why Nix community recommends using rust overlays, and not impure rustup package and I think we are suffering consequences of not listening.

Exactly this, basically.