You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
rustc could not initialize thread_rng (on pre-getrandom Linux kernel) #63848
nushell: https://book.nushell.sh/en/installation / no on-point issues seen here -- searched for "nushell"
Tried to build nushell from source and it required "nightly" rust. Didn't know how to install that, so I used "cargo install nu"
I expected to see this happen:
Build complete -- the cargo install has worked with other tools.
Instead, this happened:
thread 'rustc' panicked at 'could not initialize thread_rng: All entropy sources failed (permanently unavailable); cause: OS RNG not yet seeded (not ready yet); cause: Resource temporarily unavailable (os error 11)', /cargo/registry/src/github.com-1ecc6299db9ec823/rand-0.6.1/src/rngs/thread.rs:82:17
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/blob/master/CONTRIBUTING.md#bug-reports
note: rustc 1.37.0 (eae3437df 2019-08-13) running on x86_64-unknown-linux-gnu
note: compiler flags: -C opt-level=3 --crate-type lib
note: some of the compiler flags provided by cargo are hidden
error: Could not compile `openssl-sys`.
warning: build failed, waiting for other jobs to finish...
error: failed to compile `nu v0.2.0`, intermediate artifacts can be found at `/tmp/cargo-installbNbt6y`
Hi.
Fast reply -- thanks ! ... cheers, drl
OS, ker|rel, machine: Linux, 3.16.0-7-amd64, x86_64
Distribution : Debian 8.11 (jessie)
Linux leap 3.16.0-7-amd64 #1 SMP Debian 3.16.59-1 (2018-10-03) x86_64
GNU/Linux
On 2019-08-24 08:43, Jonas Schievink wrote:
This looks like an issue in the getrandom crate (cc @dhardy [1] @newpavlov [2]).
What distro and hardware are you building on? Can you post the output of uname -a?
--
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub [3], or mute the thread [4].
The error report uses Rand v0.6.1 which does not even use the getrandom crate. It would be nice to see if updating nu to rand 0.7 fixes the problem @jonathandturner. We are aware of a potential issue when many new thread-rngs are initialised in a short space of time: rust-random/rand#804 (fixed in recent versions of getrandom).
I don't understand why this issue was reported here, instead of against nu or rand?
changed the title [-]rustc could not initialize thread_rng[/-][+]rustc could not initialize thread_rng (on pre-getrandom Linux kernel)[/+]on Aug 25, 2019
@RalfJung that's a known issue; you must update rand_core to at least 0.3.1 at the same time. Unfortunately fixing it now would cause breakage for no_std users IIRC.
The issue with upgrading to rand 0.6.5 is described in rust-random/rand#852 rand_os is no_std crate using libcwith default features. Why does it matter?
C library is linked by std or libcwithout default features leaving rand_os with undefined references when building Rust (and probably some no_std crates), see #61393. getrandom had the same issue so I updated it in #63806 (I'll update it again tomorrow morning CEST) and this time it worked in local build.
@newpavlov:
it compiled. Do you still need a backtrace? I might not be able to replicate the problem, but it may be related to how the default was set ... cheers, drl
@newpavlov it's true the tools might not work because of the old rand but much more important is to have rustc working. #64381 should take care of it, I'll see about the tools this or next week (it's hard because upgrade has to be coordinated).
rand = { version = "0.6.1", features = ["i128_support"] }
probably need to be upgraded in single PR. I think duplicated dependencies check will fail otherwise and you'll have to revert rand upgrade but if you can make it though it'd be great.
I'll start with removing unnecessary dependencies from rustc-workspace-hack.
Status update:
I believe #64381 should have fixed this issue for rustc executable. #64384 removed removed rand dependency from rustc-workspace-hack which should allow tools to upgrade their rand dependency.
@lienke could you try next nightly (it will be released around 2019-09-17 01:00 UTC)?
To be fully precise, it'll be released around 1h later than that (the release process starts shortly after midnight UTC but it has to shuffle quite a lot of data around so it takes a bit).
Installed missing libraries, allowing build to complete, but with warnings. Assuming nu folks will deal with that. Thanks ... cheers, drl
$ cargo build --all-features && cargo run --all-features
Compiling nu v0.2.0 (/home/...)
warning: the feature `async_await` has been stable since 1.39.0 and no longer requires an attribute to enable
--> src/plugins/sys.rs:1:12
|
1 | #![feature(async_await)]
| ^^^^^^^^^^^
|
= note: `#[warn(stable_features)]` on by default
warning: the feature `async_await` has been stable since 1.39.0 and no longer requires an attribute to enable
--> src/main.rs:3:12
|
3 | #![feature(async_await)]
| ^^^^^^^^^^^
|
= note: `#[warn(stable_features)]` on by default
warning: the feature `bind_by_move_pattern_guards` has been stable since 1.39.0 and no longer requires an attribute to enable
--> src/main.rs:5:12
|
5 | #![feature(bind_by_move_pattern_guards)]
Activity
jonas-schievink commentedon Aug 24, 2019
This looks like an issue in the getrandom crate (cc @dhardy @newpavlov).
What distro and hardware are you building on? Can you post the output of
uname -a?lienke commentedon Aug 24, 2019
jonas-schievink commentedon Aug 24, 2019
That kernel version is missing the
getrandom()syscall, so perhaps there's something wrong with the fallback paths in the getrandom crate?dhardy commentedon Aug 24, 2019
The error report uses Rand v0.6.1 which does not even use the
getrandomcrate. It would be nice to see if updating nu to rand 0.7 fixes the problem @jonathandturner. We are aware of a potential issue when many new thread-rngs are initialised in a short space of time: rust-random/rand#804 (fixed in recent versions ofgetrandom).I don't understand why this issue was reported here, instead of against nu or rand?
jonas-schievink commentedon Aug 24, 2019
@dhardy the compiler is panicking due to its use of
rand, not nushell[-]Attempt to build nushell fails[/-][+]rustc could not initialize thread_rng[/+][-]rustc could not initialize thread_rng[/-][+]rustc could not initialize thread_rng (on pre-getrandom Linux kernel)[/+]RalfJung commentedon Aug 25, 2019
Not sure how much it would take to update rustc to rand 0.7.0, but updating to 0.6.5 would be easy. @dhardy do you think that could help?
RalfJung commentedon Aug 25, 2019
Actually, doing
cargo update -p rand:0.6.1breaks the build. Looks likerandaccidentally released a breaking change as a patch release?Build error
dhardy commentedon Aug 25, 2019
@RalfJung that's a known issue; you must update
rand_coreto at least 0.3.1 at the same time. Unfortunately fixing it now would cause breakage forno_stdusers IIRC.mati865 commentedon Aug 26, 2019
The issue with upgrading to rand 0.6.5 is described in rust-random/rand#852
rand_osisno_stdcrate usinglibcwith default features. Why does it matter?C library is linked by
stdorlibcwithout default features leavingrand_oswith undefined references when building Rust (and probably someno_stdcrates), see #61393.getrandomhad the same issue so I updated it in #63806 (I'll update it again tomorrow morning CEST) and this time it worked in local build.18 remaining items
newpavlov commentedon Sep 11, 2019
Can you add a backtrace?
rand 0.6.1is still a dependency for the following crates:miriparking_lot_core(v0.4.0 is used, while the latest version is v0.6)phf_generator(it was updated recently, but new version have not landed on crates.io yet)rls,rls-rustcrustc-workspace-hacktempfile(we need to just update to v3.1.0 here)tokio-threadpooluuid(the update has not yet landed on crates.io)lienke commentedon Sep 11, 2019
@newpavlov:
it compiled. Do you still need a backtrace? I might not be able to replicate the problem, but it may be related to how the default was set ... cheers, drl
mati865 commentedon Sep 11, 2019
Overrides are explained in https://github.com/rust-lang/rustup.rs#directory-overrides
I identified
parking_lot 0.7.1andtempfileasrustcdependencies pulling in old rand.mati865 commentedon Sep 11, 2019
@newpavlov it's true the tools might not work because of the old
randbut much more important is to haverustcworking.#64381 should take care of it, I'll see about the tools this or next week (it's hard because upgrade has to be coordinated).
RalfJung commentedon Sep 11, 2019
For Miri I already opened rust-lang/miri#947.
mati865 commentedon Sep 11, 2019
@RalfJung the thing is currently all the tools and
rust/src/tools/rustc-workspace-hack/Cargo.toml
Line 69 in 74d5c70
randupgrade but if you can make it though it'd be great.I'll start with removing unnecessary dependencies from
rustc-workspace-hack.RalfJung commentedon Sep 11, 2019
I don't think so. That check is for the same version of the same crate being compiled multiple times due to different feature flags.
We've had multiple versions of
memoffsetin our Cargo.lock for quite some time already.Rollup merge of rust-lang#64381 - mati865:rand, r=alexcrichton
Auto merge of #64381 - mati865:rand, r=alexcrichton
Auto merge of #64381 - mati865:rand, r=alexcrichton
mati865 commentedon Sep 16, 2019
Status update:
I believe #64381 should have fixed this issue for
rustcexecutable.#64384 removed removed
randdependency fromrustc-workspace-hackwhich should allow tools to upgrade theirranddependency.@lienke could you try next nightly (it will be released around 2019-09-17 01:00 UTC)?
edit: fixed date
RalfJung commentedon Sep 16, 2019
To be fully precise, it'll be released around 1h later than that (the release process starts shortly after midnight UTC but it has to shuffle quite a lot of data around so it takes a bit).
lienke commentedon Sep 22, 2019
Compiled with:
cargo build --all-features && cargo run --all-featuresand compile failed with several messages about
ldnot finding several items.Recompiled with:
cargo buildand finished successfully.
Versions used:
Thanks to all for dealing with this ... cheers, drl
lienke commentedon Sep 23, 2019
Installed missing libraries, allowing build to complete, but with warnings. Assuming
nufolks will deal with that. Thanks ... cheers, drl