Linking error on Rust 1.70 aarch64-unknown-linux-musl toolchain #113104
Comments
|
I think this is another manifestation of whatever is causing #111888 The root cause predates my alignment checks PR, but the non-unwinding panics that I added provoke it more often. |
jyn514
added
A-linkage
rustbot
added
the
I-prioritize
|
WG-prioritization assigning priority (Zulip discussion) and nominating for T-compiler meeting to try getting more eyes on this class of linkage error we're experiencing since 1.70 @rustbot label -I-prioritize +P-high I-compiler-nominated +T-compiler |
rustbot
added
I-compiler-nominated
|
I've carved out some time for this today and tomorrow. |
rustbot
removed
the
I-compiler-nominated
|
@geauxvirtual I'm feeling dense: Can you provide a link to a reproduction, even its just the whole project you are trying to build? I.e. you say "the project" many times in the bug description, but there's no link. If its not open-source, then without a separate minimized reproduction provided, we won't be able to ensure that whatever fix we put in actually addresses your problem. |
pnkfelix
added
the
E-needs-mcve
|
I'll see if I can put together a minimal reproduction today because the project isn't open source. |
|
I'm still working on trying to produce a minimal reproducible version of the issue, but in the process, I have been able to get the project to build on Example dependency structure below from the way the project compiled fine up to Rust 1.69 on |
|
After hitting that locally I'm now also getting this in CI for Firefox, targetting |
|
I have yet to reproduce that in anything outside of mozilla-central (the firefox repository). Full details: Error:
|
|
Still no small reproduction, but I extracted the crate and tested it in a clean Docker environment too: https://github.com/badboy/uniffi-bindgen-gecko-js-rustc-bug/ Note: removing the |
What's happening on this one is that rust creates a symbol versioning script for the uniffi-macros proc macro with the contents: IOW, it wants to export those symbols, although they are irrelevant for a proc macro. |
|
Fundamentally, though, the uniffi problem is that the proc macro is depending on uniffi_core, via uniffi_meta, and uniffi_meta only needs the metadata module of uniffi_core, but uniffi_core contains much more stuff, including those ffi exports. If that module was a separate crate (or duplicated in uniffi_meta), the problem wouldn't happen. All in all the uniffi problem may or may not be related to this issue. |
|
That sounds exactly like another source of these linker errors: https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/linker.20errs.20from.20wasm.20exposed.20by.20mir.20align.20checks.20.23111888 I'm more convinced now that there is just one bug here. |
True. |
|
@geauxvirtual can you check if the problem is resolved in the latest nightly, now that #114470 has landed? (or maybe @badboy can check against the reproducer that they concocted...) |
|
I just tried building against the latest nightly, and the same linking error above is seen with the latest nightly compiler. |
|
We just got a report of a similar bug building Deno on aarch64 using Ubuntu 16.04 (glibc 2.26.1): |
|
The symbol with a missing version is in ring, which is a direct dependency of |
|
I am looking into this. Mostly hoping to get an MCVE out of |
saethlin
removed
O-musl
|
After some awesome effort from @saethlin to produce an MCVE, it looks to me like the MCVE itself is fixed by #115114 (which ended up in the nightly-2023-08-24).... and PR #115114 does seem like something that could have an impact on this kind of thing... so ... I hate to ask again but ... can @geauxvirtual and @mmastrac check if their problem still occurs against the latest nightly? :) |
|
I was able to successfully build with both |
|
I was able to build my project with the latest nightly release. |
|
My MCVE was a bit more fragile than I hoped, and it was "fixed" by the linked PR, but the deno-arm64 build was not fixed. I've improved the MCVE, it now still encounters the linker error on nightly; the trick is that This Dockerfile will continue to reproduce the linker error on any host: |
saethlin
removed
the
E-needs-mcve
|
I unassigned myself because I have provided the MCVE and in general these kinds of problems are beyond my skills, but I think there are people on the compiler team who are able to tackle this. |
|
I thinks i'm having the same error on 1.74: let me know if you need more information |
|
@wiiznokes Are you also hitting this only on Ubuntu 16? If not, I'd love to have a reproducer I can run so that I can minimize it to see if this is the same effect that this issue evolved into. |
|
Up-thread I minimized part of deno down to 12 lines of code, I'm not afraid. Yet. |
|
It looks like this project only builds in debug mode. If I try to |
|
Wait a second, you said the error is:
which is very suspicious. Have you tried following the linker's advice? This looks like a mismatch between the flags used for a C or C++ project and a Rust project. |
|
I hadn't tested it, no. I just did this and I still get the same error. I really don't know if this is related to this issue. I don't know much in this level |
|
The linker error that this issue is about looks like Which is a different error message than you have. If your project builds on Rust 1.73 but not Rust 1.74, please open a new issue for the regression. If your project doesn't build on 1.70 but builds on 1.69 you might be seeing a very different manifestation of the underlying cause of this issue. |
|
Hi friends. I just found this issue today. I wish somebody would have let me know about it before, so I could address it. I will be looking into it soon. The thing that's special about this symbol is that it is defined as
|
|
@saethlin wrote:
Thanks. I appreciate you doing this minimization. I am planning to work around the issue in briansmith/ring#1808. |
Back on July 25th, @badboy wrote:
Indeed, 1.70.0 was the first version that included the change in PR #108017, which adds |
I have a project that currently compiles and links with Rust 1.67 on the following toolchains:
The project successfully builds with all three toolchains for Rust 1.69.
I was attempting to build the project with Rust 1.70. The project compiles successfully on the following toolchains:
The project fails to compile and link on the following toolchain:
I've been trying to track down which dependency of the project could be causing the following errors to be thrown since the project has no specific hardware requirements, but I also wanted to open an issue since this is failing for one specific toolchain starting with 1.70.
Building with
--verbosedoes not yield any additional information. This occurs for bothdebugandreleasebuilds.The text was updated successfully, but these errors were encountered: