Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.
Sign upBuilding standard library with LLD fails on Windows with "undefined symbol" errors #54190
Comments
michaelwoerister
added
A-linkage
I-ICE
O-ARM
T-compiler
C-bug
labels
Sep 13, 2018
This comment has been minimized.
This comment has been minimized.
|
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
Building standard library for "aarch64-pc-windows-msvc" fails with "undefined symbol" errors
Building standard library with LLD fails on Windows with "undefined symbol" errors
Sep 14, 2018
michaelwoerister
added
O-windows
and removed
O-ARM
labels
Sep 14, 2018
This comment has been minimized.
This comment has been minimized.
|
cc @alexcrichton, who did the initial work for supporting aarch64 in Windows. |
This comment has been minimized.
This comment has been minimized.
|
A few thoughts on fixing this:
|
This comment has been minimized.
This comment has been minimized.
|
I cargo-culted the configuration to use |
This comment has been minimized.
This comment has been minimized.
|
The original PR mentions LLD being less buggy than the MSVC linker. |
This comment has been minimized.
This comment has been minimized.
|
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? |
This comment has been minimized.
This comment has been minimized.
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. |
This comment has been minimized.
This comment has been minimized.
|
I'll give the MSVC linker a try after the weekend. |
This comment has been minimized.
This comment has been minimized.
|
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 |
This was referenced Sep 17, 2018
This comment has been minimized.
This comment has been minimized.
|
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 |
This comment has been minimized.
This comment has been minimized.
|
I thought this might be the problem: Line 523 in 2224a42 |
This comment has been minimized.
This comment has been minimized.
|
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! |
This comment has been minimized.
This comment has been minimized.
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... |
This comment has been minimized.
This comment has been minimized.
|
Oh sorry, I should explain more too! So both the The easiest fix here actually is probably just adding a |
kennytm
added a commit
to kennytm/rust
that referenced
this issue
Sep 20, 2018
michaelwoerister
referenced this issue
Sep 24, 2018
Merged
aarch64-pc-windows-msvc: Don't link libpanic_unwind to libtest. #54529
pietroalbini
added a commit
to pietroalbini/rust
that referenced
this issue
Sep 25, 2018
This comment has been minimized.
This comment has been minimized.
|
Since #54529 was merged, we can close this issue, correct? Or is it being kept open for a "proper" fix? |
This comment has been minimized.
This comment has been minimized.
|
@froydnj That fix/workaround is for a different issue (#54291). It's still not possible to link certain |
michaelwoerister commentedSep 13, 2018
•
edited
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