Closed wucke13 closed 2 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
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
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.
@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.
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
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.
Reproduce
Meta
rustc --version --verbose
:Error output
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
```