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.

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

race condition with -j# in Makefile #9531

Closed
thestinger opened this issue Sep 26, 2013 · 5 comments · Fixed by #9542
Closed

race condition with -j# in Makefile #9531

thestinger opened this issue Sep 26, 2013 · 5 comments · Fixed by #9542

Comments

@thestinger
Copy link
Contributor

Build log: http://sprunge.us/VNBW

note: /usr/bin/ld: cannot find -lrustrt

@thestinger
Copy link
Contributor Author

occurs on both i686 and x86_64, very strange

@pnkfelix
Copy link
Member

sequence of events leading to the failure, drawn from the log strcat posted, I think

link: x86_64-unknown-linux-gnu/rt/stage0/librustrt.so
link: x86_64-unknown-linux-gnu/rt/stage1/librustrt.so
link: x86_64-unknown-linux-gnu/rt/stage2/librustrt.so
cp: x86_64-unknown-linux-gnu/stage0/lib/rustc/x86_64-unknown-linux-gnu/lib/librustrt.so
cp: x86_64-unknown-linux-gnu/stage1/lib/librustrt.so
cp: x86_64-unknown-linux-gnu/stage1/lib/rustc/x86_64-unknown-linux-gnu/lib/librustrt.so
cp: x86_64-unknown-linux-gnu/stage2/lib/librustrt.so
cp: x86_64-unknown-linux-gnu/stage2/lib/rustc/x86_64-unknown-linux-gnu/lib/librustrt.so

removing x86_64-unknown-linux-gnu/stage0/lib/rustc/x86_64-unknown-linux-gnu/lib/librustrt.so
extracting rust-stage0/lib/librustrt.so

The steps that copy librustrt into the target directory are supposed to wait until the snapshot unpacking script is done downloading and unpacking, because the unpacking script cleans out the target area of "old products" before it copies its contents over.

I'll try to fix this in the makefile dependencies. But maybe its time for me to consider changing the script to not clean out the contents of stageN/lib/rustc/*/lib/. Not sure.

@thestinger
Copy link
Contributor Author

@pnkfelix: I'll try unsetting MAKEFLAGS to verify

@pnkfelix
Copy link
Member

I've replicated locally on my OS X machine with these steps:

% rm -rf *
% ../configure --enable-debug --enable-optimize  --enable-ccache --enable-clang --prefix=~/opt/rust-dbg
%  remake --trace -j16
...
note: ld: library not found for -lmorestack
clang: error: linker command failed with exit code 1 (use -v to see invocation)

error: aborting due to previous error
remake: *** [x86_64-apple-darwin/stage0/lib/rustc/x86_64-apple-darwin/lib/libstd.dylib] Error 101
Command-line invocation:
    "/Users/pnkfelix/opt-remake/bin/remake --trace -j16"

(and the same ordering, with the copy librustrt.dylib preceding the unpacking of the snapshot, takes place for me as well.)

@thestinger
Copy link
Contributor Author

Edited the title to reflect the actual bug.

@bors bors closed this as completed in 92e7bb6 Sep 28, 2013
flip1995 pushed a commit to flip1995/rust that referenced this issue Oct 6, 2022
Fix ICE in `needless_pass_by_value` with unsized `dyn Fn`

fixes rust-lang#9459

Not really sure why a query for a type implementing `FnOnce` even works since the trait if `FnOnce<T>`, but it seems to. I would have expected it to crash like it does when passing `dyn FnOnce()` as the type.

changelog: [`needless_pass_by_value`](https://rust-lang.github.io/rust-clippy/master/#needless_pass_by_value) Fix ICE in with unsized `dyn Fn` argument
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants