rust-lang / rust

Empowering everyone to build reliable and efficient software.
https://www.rust-lang.org
Other
98.69k stars 12.75k forks source link

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

Closed wucke13 closed 2 years ago

wucke13 commented 3 years ago

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::::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::::resolve_imports 10: rustc_expand::expand::MacroExpander::fully_expand_fragment 11: rustc_expand::expand::MacroExpander::expand_crate 12: rustc_session::utils::::time 13: rustc_interface::passes::configure_and_expand_inner 14: rustc_interface::passes::configure_and_expand::{{closure}} 15: rustc_data_structures::box_region::PinnedGenerator::new 16: rustc_interface::passes::configure_and_expand 17: rustc_interface::queries::Queries::expansion 18: rustc_interface::queries::::enter 19: rustc_span::with_source_map 20: rustc_interface::interface::create_compiler_and_run 21: scoped_tls::ScopedKey::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::::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::::resolve_imports 10: rustc_expand::expand::MacroExpander::fully_expand_fragment 11: rustc_expand::expand::MacroExpander::expand_crate 12: rustc_session::utils::::time 13: rustc_interface::passes::configure_and_expand_inner 14: rustc_interface::passes::configure_and_expand::{{closure}} 15: rustc_data_structures::box_region::PinnedGenerator::new 16: rustc_interface::passes::configure_and_expand 17: rustc_interface::queries::Queries::expansion 18: rustc_interface::queries::::enter 19: rustc_span::with_source_map 20: rustc_interface::interface::create_compiler_and_run 21: scoped_tls::ScopedKey::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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

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 commented 2 years ago

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.