Building standard library with LLD fails on Windows with "undefined symbol" errors #54190
Comments
michaelwoerister
added
A-linkage
|
So it turns out that linking with LLD does not work on Windows in general. At least I get the same linker errors for // In simple cases, only Name is set. Renamed exports are parsed
// and set as "ExtName = Name". If Name has the form "OtherDll.Func",
// it shouldn't be a normal exported function but a forward to another
// DLL instead. This is supported by both MS and GNU linkers.
if (E1.ExtName != E1.Name && StringRef(E1.Name).contains('.')) {
E2.Name = Saver.save(E1.ExtName);
E2.ForwardTo = Saver.save(E1.Name);
Config->Exports.push_back(E2);
continue;
}LLD interprets every symbol with a dot in it as a re-export from another DLLs. And it will find plenty of dots in our symbols I don't know yet what the best strategy to solve this is. We'll probably have to avoid dots in our symbol names entirely. |
michaelwoerister
changed the title
michaelwoerister
added
O-windows
|
cc @alexcrichton, who did the initial work for supporting aarch64 in Windows. |
|
A few thoughts on fixing this:
|
|
I cargo-culted the configuration to use |
|
The original PR mentions LLD being less buggy than the MSVC linker. |
|
Oh dear, thanks for tracking that down @michaelwoerister! I recall that LLD worked for building MSVC binaries, but I think that must have been simple binaries, I've never bootstrapped with it. It may also be the case now that LLVM and/or link.exe has progressed to being "less buggy" so it may work for aarch64 (haven't check it recently myself) We could perhaps as a temporary interim measure have different mangling on each platform? |
Yeah, Windows might be a good testing ground for a new mangling scheme as there are probably fewer tools that depend on the current scheme. |
|
I'll give the MSVC linker a try after the weekend. |
|
So it seems that MSVC has received some Aarch64 fixes meanwhile: When using This is the same error I get when compiling with LLD and a |
|
Hm that error is... curious! That shouldn't happen because we're compiling everything with For example wasm defaults to panic=abort and doesn't hit an error like that when bootstrapping. Thinking about this though... that may be related to dynamic libraries. None of our other panic=abort-by-default targets support dynamic libraries, so this error hasn't shown up before. To fix that error we'll likely need to update the |
|
I thought this might be the problem: Line 523 in 2224a42 |
|
Yeah I guess what I mean is that this isn't the first target to default to panic=abort, but we haven't run into this issue yet. That's just because all those targets don't support dylibs, so there's a number of solutions we could do here. I'm not really sure which is best, but so long as something works I'm sure it'll be fine :) If changing that line in rustbuild works, that sounds great! |
It does not, unfortunately. The workaround suggested by you does though: // in src/libpanic_unwind/lib.rs
#![cfg_attr(not(all(windows, target_arch = "aarch64")), panic_runtime)]
I don't really understand the problem yet, I think. I need to read up on panic runtime handling first... |
|
Oh sorry, I should explain more too! So both the The easiest fix here actually is probably just adding a |
…vc, r=alexcrichton Switch linker for aarch64-pc-windows-msvc from LLD to MSVC The MSVC linker does not seem to have the same problems with Rust symbols that LLD currently has on Windows (see rust-lang#54190 (comment)). This PR makes MSVC the default linker for `aarch64-pc-windows-msvc`. r? @alexcrichton
…r=alexcrichton aarch64-pc-windows-msvc: Don't link libpanic_unwind to libtest. This implements the suggestion from rust-lang#54190 (comment) in order to unbreak bootstrapping for the `aarch64-pc-windows-msvc` target. With this applied and using MSVC 15.8.3 for linking the bootstrap actually works and I can cross-compile a hello-world program. r? @alexcrichton
|
Since #54529 was merged, we can close this issue, correct? Or is it being kept open for a "proper" fix? |
|
@froydnj That fix/workaround is for a different issue (#54291). It's still not possible to link certain |
|
Triage: Now that a new mangling scheme exists: under what condition do we close this issue? When the new mangling scheme is the default scheme on Windows? |
|
That hasn't been decided yet. Also v0 symbols can still contain dots in the name. That happens with eg ThinLTO where LLVM appends |
Currently it's not possible to cross-compile the standard library for
aarch64-pc-windows-msvc. To reproduce, install the MSVC's ARM64 toolchain (I used MSVC 15.8.3) and configure Rust as follows:Running
./x.py buildwill abort with linker errors (error log provided by @froydnj):complete error log
The text was updated successfully, but these errors were encountered: