-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Multiple codegen units breaks linking: "undefined reference to rust_begin_unwind" #47074
Comments
After bisecting it seems that this broke between nightly-2017-12-27 (good) and nightly-2017-12-28 (bad). |
@alexcrichton the |
Ok cool, makes sense! In that case I believe this is indeed the same issue as #18807. The compiler knows who needs I believe the correct fix here (and for #18807) is for rustc to detect which crate defines |
ugh, I'm now seeing this linker error in another project when compiling it using the dev profile even though codegen-units is set to 1 and incremental is disabled in the Cargo.toml. My current fix is ... to enable LTO on the dev profile. @alexcrichton any chance you'll have to time soon to implement the fix you mentioned? Otherwise I can look into it next week, probably. |
@japaric unfortunately I don't think I'll have time to look into this, but I can certainly help out with questions if they come up! |
@alexcrichton alright. I'll ping you on IRC when I get a chance to look into this. |
70: work around rust-lang/rust#47074 r=japaric a=japaric
I've opened a PR for this at #49316 |
This commit fixes a longstanding issue with the compiler with circular dependencies between libcore and libstd. The `core` crate requires at least one symbol, the ability to unwind. The `std` crate is the crate which actually defines this symbol, but the `std` crate also depends on the `core` crate. This circular dependency is in general disallowed in Rust as crates cannot have cycles amongst them. A special exception is made just for core/std, but this is also unfortunately incompatible with how GNU linkers work. GNU linkers will process undefined symbols in a left-to-right fashion, only actually linking an rlib like libstd if there are any symbols used from it. This strategy is incompatible with circular dependencies because if we otherwise don't use symbols from libstd we don't discover that we needed it until we're later processing libcore's symbols! To fix this GNU linkers support the `--start-group` and `--end-group` options which indicate "libraries between these markers may have circular dependencies amongst them. The linker invocation has been updated to automatically pass these arguments when we're invoking a GNU linker and automatically calculate where the arguments need to go (around libstd and libcore) Closes rust-lang#18807 Closes rust-lang#47074
…oerister rustc: Group linked libraries where needed This commit fixes a longstanding issue with the compiler with circular dependencies between libcore and libstd. The `core` crate requires at least one symbol, the ability to unwind. The `std` crate is the crate which actually defines this symbol, but the `std` crate also depends on the `core` crate. This circular dependency is in general disallowed in Rust as crates cannot have cycles amongst them. A special exception is made just for core/std, but this is also unfortunately incompatible with how GNU linkers work. GNU linkers will process undefined symbols in a left-to-right fashion, only actually linking an rlib like libstd if there are any symbols used from it. This strategy is incompatible with circular dependencies because if we otherwise don't use symbols from libstd we don't discover that we needed it until we're later processing libcore's symbols! To fix this GNU linkers support the `--start-group` and `--end-group` options which indicate "libraries between these markers may have circular dependencies amongst them. The linker invocation has been updated to automatically pass these arguments when we're invoking a GNU linker and automatically calculate where the arguments need to go (around libstd and libcore) Closes #18807 Closes #47074
I just had something similar with It's an error in the final linking stage, but when I use
the work-around from here also helped
|
STR
Meta
cc @alexcrichton @clebi
The text was updated successfully, but these errors were encountered: