Repository navigation
Incremental occasionally causes link failures (in particular when build process is interrupted) #81280
Copy link
Copy link
Open
Labels
A-contributor-roadblockArea: Makes things more difficult for new or seasoned contributors to RustArea: Makes things more difficult for new or seasoned contributors to RustA-incr-compArea: Incremental compilationArea: Incremental compilationA-linkageArea: linking into static, shared libraries and binariesArea: linking into static, shared libraries and binariesC-bugCategory: This is a bug.Category: This is a bug.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.
Description
I tried this code: b717882
I expected to see this happen: It compiles successfully.
Instead, this happened:
= note: /usr/bin/ld: /tmp/rustc7n3dgo/librustc_typeck-c1c702f6c0ed082b.rlib(rustc_typeck-c1c702f6c0ed082b.1f6gvdzw1xg6y56.rcgu.o): relocation R_X86_64_PC32 against undefined hidden symbol `anon.e321930b0bae74a5b269c2d224f94109.135.llvm.15012941867981504210' can not be used when making a shared object
/usr/bin/ld: /tmp/rustc7n3dgo/librustc_typeck-c1c702f6c0ed082b.rlib(rustc_typeck-c1c702f6c0ed082b.2kv783dkfz4eig4n.rcgu.o): relocation R_X86_64_PC32 against undefined hidden symbol `_ZN4core3ops8function6FnOnce9call_once17hb43433e1ee944fe7E.llvm.14317370391725333118' can not be used when making a shared object
/usr/bin/ld: /tmp/rustc7n3dgo/librustc_typeck-c1c702f6c0ed082b.rlib(rustc_typeck-c1c702f6c0ed082b.3cqtg0ebrql2rd8.rcgu.o): relocation R_X86_64_PC32 against undefined hidden symbol `anon.eae49e7385ecc193ec1fcf539c5141a9.100.llvm.5499732698529515802' can not be used when making a shared object
/usr/bin/ld: /tmp/rustc7n3dgo/librustc_middle-83b74242a7255742.rlib(rustc_middle-83b74242a7255742.29ntjh109p85p91e.rcgu.o): relocation R_X86_64_PC32 against undefined hidden symbol `anon.712e2f39c61ddadde64034dfaf0f738c.199.llvm.18382006748427464360' can not be used when making a shared object
/usr/bin/ld: /tmp/rustc7n3dgo/librustc_middle-83b74242a7255742.rlib(rustc_middle-83b74242a7255742.38uvgcbj494cplao.rcgu.o): relocation R_X86_64_PC32 against undefined hidden symbol `anon.712e2f39c61ddadde64034dfaf0f738c.199.llvm.18382006748427464360' can not be used when making a shared object
/usr/bin/ld: /tmp/rustc7n3dgo/librustc_middle-83b74242a7255742.rlib(rustc_middle-83b74242a7255742.3hr9th0q5c43xr2a.rcgu.o): relocation R_X86_64_PC32 against undefined hidden symbol `anon.82495b045438102480b0340cffb3c8e7.100.llvm.17830998827333553218' can not be used when making a shared object
/usr/bin/ld: /tmp/rustc7n3dgo/librustc_middle-83b74242a7255742.rlib(rustc_middle-83b74242a7255742.44bsww8uk85mfq3a.rcgu.o): relocation R_X86_64_PC32 against undefined hidden symbol `anon.712e2f39c61ddadde64034dfaf0f738c.199.llvm.18382006748427464360' can not be used when making a shared object
/usr/bin/ld: /tmp/rustc7n3dgo/librustc_middle-83b74242a7255742.rlib(rustc_middle-83b74242a7255742.4iywqxra088mgqr5.rcgu.o): relocation R_X86_64_PC32 against undefined hidden symbol `anon.712e2f39c61ddadde64034dfaf0f738c.389.llvm.18382006748427464360' can not be used when making a shared object
/usr/bin/ld: /tmp/rustc7n3dgo/librustc_middle-83b74242a7255742.rlib(rustc_middle-83b74242a7255742.4s1s3wicvbdoxsru.rcgu.o): relocation R_X86_64_PC32 against undefined hidden symbol `anon.f6101ecacd895ad87283c593f614ce01.72.llvm.3245620587429400994' can not be used when making a shared object
/usr/bin/ld: /tmp/rustc7n3dgo/librustc_middle-83b74242a7255742.rlib(rustc_middle-83b74242a7255742.5fsy1y6w5w7prvy9.rcgu.o): relocation R_X86_64_PC32 against undefined hidden symbol `anon.712e2f39c61ddadde64034dfaf0f738c.199.llvm.18382006748427464360' can not be used when making a shared object
/usr/bin/ld: /tmp/rustc7n3dgo/librustc_middle-83b74242a7255742.rlib(rustc_middle-83b74242a7255742.zjtxsb10gpjb46g.rcgu.o): relocation R_X86_64_PC32 against undefined hidden symbol `anon.82495b045438102480b0340cffb3c8e7.100.llvm.17830998827333553218' can not be used when making a shared object
/usr/bin/ld: final link failed: nonrepresentable section on output
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Meta
rustc --version:
rustc 1.50.0-beta.1 (05b602367 2020-12-29)
cc @Aaron1011 , I think you were looking into something similar a while back.
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
A-contributor-roadblockArea: Makes things more difficult for new or seasoned contributors to RustArea: Makes things more difficult for new or seasoned contributors to RustA-incr-compArea: Incremental compilationArea: Incremental compilationA-linkageArea: linking into static, shared libraries and binariesArea: linking into static, shared libraries and binariesC-bugCategory: This is a bug.Category: This is a bug.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.
Activity
petrochenkov commentedon Dec 24, 2021
Just got this error while linking
rustc_driverwith incremental enabled (not for the first time).petrochenkov commentedon Dec 24, 2021
cc #85309 #86049
petrochenkov commentedon Dec 24, 2021
Again:
RalfJung commentedon Feb 6, 2023
This is particularly likely to happen when the build process is interrupted, e.g. via Ctrl-C
[-]Incremental occasionally causes link failures[/-][+]Incremental occasionally causes link failures (in particular when build process is interrupted)[/+]RalfJung commentedon Nov 28, 2023
I'm running into the Ctrl-C issue fairly regularly. It's quite frustrating when a simple
./x.py fmtis blocked on a long-running build job but one can't cancel the build job since that poisons the cache in really hard to fix ways... and the chances of getting a poisoned cache when doing Ctrl-C while rustc is being built are very high.Cc @rust-lang/wg-incr-comp is there anything that can be done to make rustc be "Ctrl-C safe", or least not as blatantly "Ctrl-C unsafe" as it is today?
michaelwoerister commentedon Nov 28, 2023
We could start to collect some data on what the root cause might be:
RalfJung commentedon Nov 28, 2023
When does the linker run?
I have this occur regularly when I interrupt while half a dozen rustc_ crates are still being built. I think the linker only runs once at the end for the main rustc binary? If that is the case, then the answer to this question is "no".
michaelwoerister commentedon Dec 4, 2023
Yes, that sounds right.
Incr. comp. protects itself against cache corruption by writing everything to a temporary session directory and only when things have reached a valid state, it will "commit" that directory, so it will be used by subsequent compilation sessions. One cause for the problem might be that rustc declares the state to be valid too early, e.g. while LLVM or rustc itself are still in the process of writing files to disk. Or that the interruption is not recognized as a failure and a half-written object file or LLVM bitcode file is cached.
I'm wondering if we can narrow down where exactly the interruption needs to happen for this to occur.
saethlin commentedon Sep 21, 2024
Are people still running into this? I'm trying to reproduce it and no luck yet.
Steveplays28 commentedon Nov 9, 2024
I'm running into this issue consistently on
rustc 1.84.0-nightly (b91a3a056 2024-11-07), I can reproduce it usingcargo watch -x 'run'.My project is a Bevy
v0.14project with the following.cargo/config.toml:The note below the error:
jangler commentedon Dec 22, 2024
I have this issue regularly using rustc 1.82.0. I used to think I had to do a
cargo cleanwhen I encountered it, but now it seems like I can justcargo runagain and it works? For me it's usually at random rather than due to an interrupted build.Edit: encountered again after an interrupt; had to
cargo clean.ActuallyHappening commentedon Jan 23, 2025
Getting very similar errors on nightly cargo 1.86.0-nightly (045bf21b3 2025-01-17)
saethlin commentedon Jan 23, 2025
It's well-established now that this problem is still ongoing. What would help is someone providing a way to reproduce these problems on-demand, even if involves waiting a few minutes for a script to run compiling a big project in a loop and randomly interrupting it. Anything that can reproduce this cascade of linker errors on-demand within like an hour would be a great step forward.
johanhelsing commentedon Sep 9, 2025
This usually happens within 10-20 minutes for me if I develop Bevy projects with "cargo watch -cx run". So if someone else wants to try to reproduce, maybe:
building: Re-enable dynamic linking
building: Re-enable dynamic linking
building: Re-enable dynamic linking
cite the rustc issue behind undefined data symbols
add an integration fixture with an undefined extern data symbol
tolerate undefined data symbols in emitted modules (#59)