cargo build hangs when using cc >= 1.0.80 (workaround in crate version 0.84.4)
#480
Comments
|
I have the same issue here under Linux, but with version 0.83. I'm almost thinking this problem has another source, because the last weeks the build process was running normal. Can it be, that it is related to the cc create, or another? Because when I revert my Cargo.lock file to an older state it works. But when I run Edit: Yes I'm almost sure is the cc-rs crate, when you revert to 1.0.79 is works. |
|
Indeed! It works for 1.0.79. For anyone who faces this issue. The following snippet of code in [patch.crates-io]
cc = { git = "https://github.com/rust-lang/cc-rs.git", version = "1.0", tag = "1.0.79" }Then run |
|
The problem was introduced in |
|
Thanks for the investigation! I’ll try to update the Cargo.toml to exclude the affected versions |
|
@bazhenov, are you sure that 1.0.80 introduced this bug? I had the intention that the bug come up with 1.0.81. We should also create a report. |
Hm... I'm sure it works in my environment on 1.0.79 and doesn't work on 1.0.80 and 1.0.81. So it seems like so, but I will not bet on it at this point 😀
I mention this issue in the rust-lang/cc-rs#841 because it seems like they are related. I will create separate report if it will turn out as an independent issue. |
|
Only change in cc v1.0.81 is to accept non-utf8 output from compiler, this problem doesn't seem like a utf-8 problem (which should cause panic), so I'd say probably both v1.0.{80, 81} is affected and would better report it as a new issue. |
|
@bazhenov From your stack trace, I can see that This should not happen in |
|
I can reproduce the problem locally on |
|
Ok, I realize there could be one bug in cc::Build::compile_objects that caused this: Wait-thread could exit early due to error, however the spawn-thread will go on and keep spawning, thus eventually hitting a deadlock. Would open a PR shortly. |
twistedfall
changed the title
cc >= 1.0.80 (workaround in crate version 0.84.4)
|
I looks like, that opencv is now in conflict with the ring crate. In my project I wanted to update jsonwebtoken to version 9, but it depends on ring version v0.17.4, and that wants cc v1.0.83. Any idea how to fix that? Full error message is: |
|
Can you try running |
|
No , if I run that, I get immediately the same error. I also run cargo clean and When I downgrade jsonwebtoken to version 8 again, it works again. |
|
Well, there are some problems with dependencies:
So at this moment I can't bump |
|
Yes, I understand. I can stick on jsonwebtoken v8 for now. |
|
P.S. I'm working on rust-lang/cc-rs#889 which completely removes jobserver as a dependency of cc by using vendored implementation and it also removes thread creation in parallel |
|
Bad news is that cc now has marv of 1.53 rust-lang/cc-rs#889 (comment) but it seems that this crate has a msrv of 1.59 so not affected |
|
Hi @NobodyXu, it looks like there is an issue with contested resources in the new version of |
|
Hi @twistedfall , are you still using jobserver along with cc? If that's the case, it's probably just the old bug hitting back rust-lang/jobserver-rs#57 . Since cc's own vendored jobserver implementation now sets the jobserver fd as non-blocking, with the bug it might have set stderr as non-blocking accidentally. However, there's a workaround. If you call cc's Any |
|
Thanks, I'll try to employ this workaround! |
|
Any luck with the workaround? |
|
Well, the version 1.0.84 that the workaround was applicable to has since been yanked (because of rust-lang/cc-rs#902) and no new version has been released so situation hasn't really changed. |
|
@torsteingrindvik Can you please check the |
This branch works for me (i.e. cargo dependencies resolve now and no compile issues) and a brief test didn't show any problems. |
|
This should now be fixed in v0.88.8 (at the cost of bumping MSRV from 1.65 to 1.66) |
brew install opencvcargo buildcommand hangs. Seems like the build scripts is waiting output of thecccompiler:But I see no compiler process running on behalf of build script:
Maybe compiler failed with some error, but it's not displayed on the screen.
The text was updated successfully, but these errors were encountered: