-
Notifications
You must be signed in to change notification settings - Fork 13.6k
Open
Labels
A-linkersArea: linkers... you gotta love linkersArea: linkers... you gotta love linkersC-discussionCategory: Discussion or questions that doesn't represent real issues.Category: Discussion or questions that doesn't represent real issues.T-bootstrapRelevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)
Description
@Kobzol Chromium builds its Rust toolchain against a specific LLVM revision. I'm adding the wasm32-unknown-unknown
target to that toolchain, so I need rust-lld
to be available. It was working correctly until this PR, but now the stage1
compiler no longer generates rust-lld
. I'm uncertain whether just copying lld
as rust-lld
would work across all platforms — I suspect there may be compatibility issues. Curious about your thoughts.
Metadata
Metadata
Assignees
Labels
A-linkersArea: linkers... you gotta love linkersArea: linkers... you gotta love linkersC-discussionCategory: Discussion or questions that doesn't represent real issues.Category: Discussion or questions that doesn't represent real issues.T-bootstrapRelevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)
Type
Projects
Milestone
Relationships
Development
Select code repository
Activity
Kobzol commentedon Apr 29, 2025
Conceptually, it seems to me that if you're using "bring your own LLVM", where the LLVM isn't shipped in the sysroot and is provided externally, then it should also mean "bring your own LLD". How do you handle shipping the LLVM to the users of the Rust toolchain that you build? Could you handle shipping the LLD in the same way? I'm asking because when an external LLVM config is used, bootstrap doesn't attach LLVM to the rustc sysroot (but it did attach LLD to the sysroot before #139853).
Also, I'm still trying to find out how does
wasm32-unknown-unknown
figure out that it should use the self-contained LLD linker (rust-lld
), rather than using a globally available LLD linker, as I don't see it in the target spec.szilardszaloki commentedon Apr 29, 2025
I can package
lld
the same way Chromium distributes its toolchain; I just wasn't certain whether copyinglld
asrust-lld
would consistently work across all platforms — could you confirm?szilardszaloki commentedon Apr 29, 2025
As for how
wasm32-unknown-unknown
knows to userust-lld
:rust/compiler/rustc_target/src/spec/base/wasm.rs
Lines 89 to 91 in efcbb94
cuviper commentedon Apr 29, 2025
FWIW, in Fedora we've been directly patching those spec "rust-lld" lines to "lld" to use our external linker, but I'd love for that to be smarter. ISTR the work to switch to
lld
on host targets likex86_64-unknown-linux-gnu
did have some logic for that? (or at least, it was planned...)Kobzol commentedon Apr 29, 2025
So, I can't really promise that your
lld
will work correctly in all cases asrust-lld
would. However, before #139853, bootstrap (by accident) copied LLD from the external location (fromllvm-config
) into the sysroot and just renamed it asrust-lld
. So if this was working for you before, then just renaming yourlld
asrust-lld
should continue working.szilardszaloki commentedon Apr 29, 2025
@Kobzol Fair enough, thanks. Out of curiosity, are there any specific scenarios you think it might break in?
Kobzol commentedon Apr 29, 2025
Not anything particular, no (I don't know in what situations is the logic of the LLD wrapper required).
rust-lld
is no longer distributed if you link against a custom LLVM brave/brave-browser#45769bjorn3 commentedon Apr 30, 2025
The lld wrapper is only required when passing
-fuse-ld=lld
to gcc or clang as linker driver I believe as GCC will specifically look forld.lld
, and clang can't pass-flavor ld
as first argument to tell lld which linker interface to use I think.szilardszaloki commentedon Apr 30, 2025
Thanks, guys — that's very helpful.