Linker error with wasm target with spaces in install path #76466
Comments
|
I checked more versions and found the nightly introducing the issue: Good: Bad: I see that LLVM was upgraded from 10 to 11 in that nightly. Was this a regression in LLD? |
|
Let’s bisect this. @rustbot ping cleanup |
|
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good cc @AminArria @camelid @chrissimpkins @contrun @DutchGhost @elshize @ethanboxx @h-michael @HallerPatrick @hdhoang @hellow554 @imtsuki @kanru @KarlK90 @LeSeulArtichaut @MAdrianMattocks @matheus-consoli @mental32 @nmccarty @Noah-Kennedy @pard68 @PeytonT @pierreN @Redblueflame @RobbieClarken @RobertoSnap @robjtede @SarthakSingh31 @senden9 @shekohex @sinato @spastorino @turboladen @woshilapin @yerke |
|
Assigning Would be great, though, to gain a bit more insight about this issue. Feel free to adjust priority upon closer investigation. |
|
@rustbot ping windows |
|
Hey Windows Group! This bug has been identified as a good "Windows candidate". cc @arlosi @danielframpton @gdr-at-ms @kennykerr @luqmana @lzybkr @retep998 @rylev @sivadeilra |
|
Given that the linker input string contains Someone should debug LLD and figure out where those strings are getting split up incorrectly. |
|
We did a bit of a deeper dive than expected into this bug during this week's T-compiler planning meeting. The relevant portion of the log starts at around here Investigation is ongoing |
|
Summarizing from the Zulip discussion: I believe this was introduced by llvm/llvm-project@928e9e1, which fixed parsing "response files" ( I expect all we need to do is pass Alternatively, we could try and come up with an escaping method that is a superset of the two implemented variants: rust/compiler/rustc_codegen_ssa/src/back/link.rs Lines 1148 to 1181 in b984ef6 Then it wouldn't matter what style is expected, it would always be correct. I believe our Windows escaping would be valid everywhere, at least from briefly reading the comments in the snippet above, so we could just always use that. |
|
assigning self to figure out if this is also a stable-to-beta regression, and if so, identify a beta-backportable fix. |
|
(yes, it affects beta, and basically breaks LDD usage on windows, which means it breaks wasm32-unknown-unknown targets on Windows.) Upgrading priority to P-critical to reflect importance of addressing this. (Luckily @eddyb has already outlined some reasonable solutions, as discussed above.) |
|
Hurm. My local windows virtual box ran I haven't dug deeply into why it doesn't reproduce the problem, beyond checking the recent git log info for llvm and for rust to see if anyone secretly fixed this. My main point in reporting this here is to say that I am not confident I'll be able to fix the bug if I cannot reproduce it via a local build. |
|
@jminer or someone else who can reproduce this, could you try the try build? You should be able to use the following: |
|
I installed from these URLs: And |
I just tried a basic wasm project:
Cargo.toml:
main.rs:
and compiled with
cargo build --target wasm32-unknown-unknown. This worked with the nightly from 2020-06-13. However, now I get a linker error:It looks like spaces in the path aren't handled correctly. I installed Rust using the msi installer and then unzipped the wasm32-unknown-unknown standard library in the correct folder. Does someone know what changed in the past three months? Otherwise, I can check in-between versions to narrow down the regression. I can still build for x86 and thumbv7m targets without a linker error.
rustc --version --verbose:I'm using Windows 10 64-bit.
The text was updated successfully, but these errors were encountered: