Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

rustc fails w/ io_error on F18, i686 #10864

Closed
itdaniher opened this issue Dec 9, 2013 · 4 comments
Closed

rustc fails w/ io_error on F18, i686 #10864

itdaniher opened this issue Dec 9, 2013 · 4 comments

Comments

@itdaniher
Copy link
Contributor

I'm using a stage2 build cross-compiled on a x86_64 F19 machine. I've also tried using the stage0 snapshots at

http://static.rust-lang.org/stage0-snapshots/rust-stage0-2013-11-28-859c3ba-linux-i386-072e638a6a11f7d00cf2c7b487162d0d2e3b5036.tar.bz
http://static.rust-lang.org/stage0-snapshots/rust-stage0-2013-12-07-49b751d-linux-i386-e3c11032b19a74b86b5b6f271ee7457ce0b00d48.tar.bz2

All fail with the following error:

task 'rustc' failed at 'Unhandled condition: io_error: io::IoError{kind: OtherIoError, desc: "no such file or directory", detail: None}', /home/it/projects/rust/src/libstd/condition.rs:131
error: internal compiler error: unexpected failure

I jumped ran in gdb using:

gdb --args ./glibc-2.17-4.fc19.i686/lib/ld-linux.so.2 --library-path $PWD/glibc-2.17-4.fc19.i686/lib:$PWD/stage2:$PWD/stage2/lib/rustc/i686-unknown-linux-gnu ./stage2/bin/rustc -L ./stage2/lib/ -L ./stage2/lib/rustc/ stage2/main.rs

and narrowed the error down to:

task 'rustc' failed at 'assertion failed: res as int != 0', /home/it/projects/rust/src/libextra/flate.rs:84

It's worth noting that the glibc path hack is not necessary for the snapshots, but they do require manually passing the library search flag via rustc -L.

The original error resembles that described at #10754 and potentially addressed in part by #10863.
@alexcrichton
Copy link
Member

I'm not sure that the unhandled condition and the assertion error are quite related, but the assertion error is somehow probably related to deflation of metadata hitting an error. When you say that you're using the stage0 snapshots, what do you mean by that? Are the steps to produce this simply to check out the repo and run make or are the some more things in play?

I think that the -L directories your passing to gdb may be containing different versions of the same library which may be causing flate to go haywire, but the original unhandled condition problem is disturbing. Could you get a backtrace for when the unhandle condition error is thrown?

@itdaniher
Copy link
Contributor Author

When you say that you're using the stage0 snapshots

I'm using the stage0 bootstrap snapshots from the links above. They're stripped of debug info, which makes life a little difficult.

I've also tried cross-compiling, but I have a different glibc on my F18 and F19 machines, requiring a bit of path hackery.

Could you get a backtrace for when the unhandle condition error is thrown?

Not past what I've been able to produce - stripped info, etc.

Are the steps to produce this simply to check out the repo and run make or are the some more things in play?

The machine I'm trying to run rustc on has a whopping 256MB of RAM, so compiling rust in situ is a bit of a stretch.

@treeman
Copy link
Contributor

treeman commented Sep 10, 2014

Triage bump.

@itdaniher status?

@itdaniher
Copy link
Contributor Author

My creative solution was to abandon trying to run rustc on that platform. If nobody's reproduced in the interim, bug is probably on my end. Closing issue.

flip1995 pushed a commit to flip1995/rust that referenced this issue Jun 30, 2023
@bors
Auto merge of rust-lang#10864 - y21:issue10437, r=blyxyas,xFrednet
b033883 
[`unnecessary_lazy_eval`]: don't lint on types with deref impl

Fixes rust-lang#10437.
This PR changes clippy's util module `eager_or_lazy` to also consider deref expressions whose type has a non-builtin deref impl and not suggest replacing it as that might have observable side effects.
A prominent example might be the `lazy_static` macro, which creates a newtype with a `Deref` impl that you need to go through to get access to the inner value. Going from lazy to eager can make a difference there.

changelog: [`unnecessary_lazy_eval`]: don't lint on types with non-builtin deref impl
flip1995 pushed a commit to flip1995/rust that referenced this issue Jun 30, 2023
@bors
Auto merge of rust-lang#10896 - y21:eager-or-lazy-autoderef, r=blyxya…
7c34ec8 
…s,xFrednet

consider autoderef through user-defined `Deref` in `eager_or_lazy`

Fixes rust-lang#10462

This PR handles autoderef in the `eager_or_lazy` util module and stops suggesting to change lazy to eager if autoderef in an expression goes through user defined `Deref` impls, e.g.
```rs
struct S;
impl Deref for S {
  type Target = ();
  fn deref(&self) -> &Self::Target { &() }
}

let _ = Some(()).as_ref().unwrap_or_else(|| &S); // autoderef `&S` -> `&()`
```

changelog: [`unnecessary_lazy_evaluations`]: don't suggest changing lazy evaluation to eager if autoderef goes through user-defined `Deref`

r? `@xFrednet`  (because of the earlier review in rust-lang#10864, might help for context here)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@itdaniher @alexcrichton @treeman