-
Notifications
You must be signed in to change notification settings - Fork 13.3k
rustc randomly fail to link with C program #111083
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
Comments
Are you using two separate rustc invocations or a single with two |
2 separate innovations running in parallel, see the makefile in my test case above. |
If I'm right and rustc write temporary files (probably .o files) that could clash between both invocations, is there a way to tell rustc where to write its temp files? That way I can easily give a different dir to each invocations. |
You could add a different |
Ideally we should have a single invocation indeed, but that would require a bit more refactoring in Meson to work like that. I'll try -Cmetadata=value argument to see if that can work around the problem for now, thanks. |
@bjorn3 I can confirm that passing |
|
Is there a downside in changing that "stable crate id" by adding the name of the final artifact to avoid conflicts? Like Using different One thing I noticed with |
There shouldn't be. The "stable crate id" is only relevant when linking against a rust crate. The cdylib and staticlib crate types don't allow linking against it as rust crate anyway.
You can combine
Makes sense. |
Awesome, that's a workable solution for me I think. Thanks. I still think this should be fixed at rustc level, even if it's not the indented usage, by ensuring temp files are put in randomized temp directories. |
Rustc does not produce object files we can reuse to build both libraries. Ideally this should be done with a single target that has both `--crate-type` arguments instead of having 2 different build rules. As temporary workaround, build twice and ensure they don't get conflicts in intermediary files created by rustc by passing target's private directory as --out-dir. See rust-lang/rust#111083.
Rustc does not produce object files we can reuse to build both libraries. Ideally this should be done with a single target that has both `--crate-type` arguments instead of having 2 different build rules. As temporary workaround, build twice and ensure they don't get conflicts in intermediary files created by rustc by passing target's private directory as --out-dir. See rust-lang/rust#111083.
Rustc does not produce object files we can reuse to build both libraries. Ideally this should be done with a single target that has both `--crate-type` arguments instead of having 2 different build rules. As temporary workaround, build twice and ensure they don't get conflicts in intermediary files created by rustc by passing target's private directory as --out-dir. See rust-lang/rust#111083.
Rustc does not produce object files we can reuse to build both libraries. Ideally this should be done with a single target that has both `--crate-type` arguments instead of having 2 different build rules. As temporary workaround, build twice and ensure they don't get conflicts in intermediary files created by rustc by passing target's private directory as --out-dir. See rust-lang/rust#111083.
Rustc does not produce object files we can reuse to build both libraries. Ideally this should be done with a single target that has both `--crate-type` arguments instead of having 2 different build rules. As temporary workaround, build twice and ensure they don't get conflicts in intermediary files created by rustc by passing target's private directory as --out-dir. See rust-lang/rust#111083.
Rustc does not produce object files we can reuse to build both libraries. Ideally this should be done with a single target that has both `--crate-type` arguments instead of having 2 different build rules. As temporary workaround, build twice and ensure they don't get conflicts in intermediary files created by rustc by passing target's private directory as --out-dir. See rust-lang/rust#111083.
Rustc does not produce object files we can reuse to build both libraries. Ideally this should be done with a single target that has both `--crate-type` arguments instead of having 2 different build rules. As temporary workaround, build twice and ensure they don't get conflicts in intermediary files created by rustc by passing target's private directory as --out-dir. See rust-lang/rust#111083.
Rustc does not produce object files we can reuse to build both libraries. Ideally this should be done with a single target that has both `--crate-type` arguments instead of having 2 different build rules. As temporary workaround, build twice and ensure they don't get conflicts in intermediary files created by rustc by passing target's private directory as --out-dir. See rust-lang/rust#111083.
Rustc does not produce object files we can reuse to build both libraries. Ideally this should be done with a single target that has both `--crate-type` arguments instead of having 2 different build rules. As temporary workaround, build twice and ensure they don't get conflicts in intermediary files created by rustc by passing target's private directory as --out-dir. See rust-lang/rust#111083.
Here is a minimal test case to reproduce: https://github.com/xclaesse/rustc-bug.
I believe this is the same issue than #55931 initially discovered this issue while working on this Meson PR: mesonbuild/meson#11714.
I suspect the problem is when compiling both cdylib and staticlib for the same stuff.rs with the same crate name, they use some common intermediary files.
The text was updated successfully, but these errors were encountered: