-
Notifications
You must be signed in to change notification settings - Fork 211
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix weak linkage on windows and apple platforms #672
Conversation
There were some issues regarding windows and apple platform, we were exporting symbols that are already provided by the compiler but weren't marked as `weak` which resulted in conflicted symbols in the linking process. Initially, we didn't add `weak` because we thought it is not supported on windows and apple platforms, but it looks like its only not supported on windows-gnu platforms Signed-off-by: Amjad Alsharafi <26300843+Amjad50@users.noreply.github.com>
Thanks for the fix, this matches what was in |
Could you create a PR to rust-lang/rust updating compiler-builtins 0.1.120 after the release PR merges? #671 |
Looks like it crashes for some reason on windows-gnu, for some reason with |
Sure |
…r=tgross35 Update `compiler_builtins` to `0.1.120` Includes rust-lang/compiler-builtins#672 which fixes regression issue with Apple and Windows compilers. r? `@tgross35`
Do you have full error messages? |
@@ -256,7 +256,7 @@ macro_rules! intrinsics { | |||
#[cfg(all(any(windows, target_os = "uefi"), target_arch = "x86_64", not(feature = "mangled-names")))] | |||
mod $name { | |||
#[no_mangle] | |||
#[cfg_attr(all(not(windows), not(target_vendor = "apple")), linkage = "weak")] | |||
#[cfg_attr(not(all(windows, target_env = "gnu")), linkage = "weak")] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It should likely also check not(target_abi = "llvm"
, how do you test it? I'd like to test with gnullvm.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just testing this crate locally? You should be able to cd
to testcrate
and cargo test --target ...
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, I thought this issue would manifest only during Rust build, gonna look into it this weekend.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The rust-lang/rust update of compiler-builtins merged, so it should also be available to test with the next rustc nightly (couple hours after 0:00 UTC)
…<try> Update `compiler_builtins` to `0.1.120` Includes rust-lang/compiler-builtins#672 which fixes regression issue with Apple and Windows compilers. try-job: aarch64-apple try-job: x86_64-apple-1 try-job: x86_64-msvc
The error messages are at the PR linked there #660, direct link https://github.com/rust-lang/compiler-builtins/actions/runs/10257106333/job/28377511730?pr=660. Basically a lot of
MSVC does support some form of weak linking, see #653 and a comment about DLLs there. We were already using this for arm functions so it seems to have worked, see the changes to Are you usually able to link windows-gnu binaries with weak symbols? |
Bummer, it requires inspection of the objects and won't be as simple as hoped.
Yeah, that's caused by an outdated linker. It's harmless but causes binaries to contain more symbols than they need to (MSVC behaves the same way modulo the warnings as this is LLVM's invention).
Oh, I haven't heard about them before. Regarding DLLs, there is a "we have weak symbols at home" attribute called
As long as they all come from static libraries and all are resolved (Windows binaries cannot contain undefined references) they seem to work. They fall apart when you try to use them inside DLLs. |
Do you have any specific concerns about the change here, or just that it would be ideal if they worked on windows-gnu too? I ran a msvc try job on the update PR at rust-lang/rust#129400 and it passed, so I don't think there is anything too worrying. Especially since it seems builtins always gets statically linked, per my comment here #653 (comment) - are weak symbols for DLLs still relevant with this in mind? For what it's worth, if there is a newer linker version that doesn't hit the listed errors then feel free to send a PR updating our CI jobs here as needed. I ran into it here too #667. |
…r=tgross35 Update `compiler_builtins` to `0.1.120` Includes rust-lang/compiler-builtins#672 which fixes regression issue with Apple and Windows compilers. try-job: aarch64-apple try-job: x86_64-apple-1 try-job: x86_64-msvc
Rollup merge of rust-lang#129400 - Amjad50:update-compiler-builtins, r=tgross35 Update `compiler_builtins` to `0.1.120` Includes rust-lang/compiler-builtins#672 which fixes regression issue with Apple and Windows compilers. try-job: aarch64-apple try-job: x86_64-apple-1 try-job: x86_64-msvc
Regarding
There should be no problem for MSVC since weak symbols were just proven to work. I'm concerned only about windows-gnu breaking during some supposedly irrelevant changes.
I attempted to build a new version with recent components using crosstool-ng to save time (I was terribly wrong here...) and wasted dozens of hours on it: https://github.com/mati865/mingw-build rust-lang/rust#119229 |
Would you mind opening a new issue so we can keep a better eye on this? |
TBH I have no idea how they are used and whats their purpose, so I cannot answer that.
Regarding FWIW I've tested both windows-gnu and windows-gnullvm locally with PR reverted. Running
Either CI GNU C toolchain (the linker and stuff) has a bug, or this error happens before reaching CI's error. Also it struck me just now, the 64-bit target has passed, so this might be an issue with name mangling. 32-bit targets (all of them, be it GNU, LLVM, MSVC) use additional underscore before symbol names. Maybe that's the problem here? |
Whatever you would like to continue investigating or are still looking into :) I just don't want to continue discussion on a merged PR, so you can repost the above couple comments to a new issue. |
Fixes #653
There were some issues regarding windows and apple platform, we were exporting symbols that are already provided by the compiler but weren't marked as
weak
which resulted in conflicted symbols in the linking process.Initially, we didn't add
weak
because we thought it is not supported on windows and apple platforms, but it looks like its only not supported on windows-gnu platforms