-
-
Notifications
You must be signed in to change notification settings - Fork 127
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
Apple LTO distributions may not weakly reference symbols on CPython 3.10+ #216
Comments
I think we're running into LLVM / ld bug llvm/llvm-project#52778, where the linker doesn't preserve weak references during LTO. This bug was introduced in LLVM 13 and fixed in LLVM 14. Our custom LLVM toolchain doesn't (yet) ship lld and
Those are Apple's LLVM versions. While I think Apple's LLVM 15.0 should be new enough, it is possible that I produced an LLVM toolchain with lld and macOS CI seems to pass with this toolchain. So I'm moderately confidence this is the issue. That's a pretty nasty bug for Apple to be shipping in their Xcode toolchain :/ |
OK. So I triggered CI against my pre-release LLVM toolchains with LLD. The good news is x86-64 builds appear to be handling weak symbols properly when using the bundled lld linker. The bad news is m4 craps out when building on macOS ARM. I'm able to reproduce the issue locally. Best I can tell m4's It initially fails the Most weird. It looks like m4's configure script just doesn't know how to handle modern lld on Apple ARM hardware. This is the kind of problem I expected to find ~3.5 years ago when Apple ARM machines launched. I thought all notable software had accounted for this. But I guess m4 is a laggard? |
Ok. I switched my custom LLVM toolchains to build on the new GitHub Actions Apple ARM runners. For whatever reason LLVM's CMake is detecting the host triple as How LLVM's CMake is thinking the GitHub Actions ARM runners are x86-64 I'm not yet sure. What a yak shave :/ |
From a
Why this is happening I'm not sure. But at least we know where things are failing. |
I'm spinning new LLVM toolchains now. Since the test build of the new LLVM toolchain with lld passed CI on x86-64, I'm optimistic the aarch64 builds will just work once the new LLVM toolchain is in place. |
Note that that LLVM bug you reference was a LLD bug, and /usr/bin/ld is not LLD. It's a completely different linker, it's not even the ld64 referenced in the LLD bug. |
Oh right. You just reminded me that Apple implemented a new, faster linker, which they announced at WWDC in June 2023. This makes a lot more sense. And explains why weak symbol issues only surfaced when upgrading CI runners to newer macOS versions. For whatever reason I thought ld was lld under the hood. |
When attempting to upgrade GitHub Actions runners and building MacOS SDKs past the old versions we're currently using, various builds started failing validation because our custom code for validating that all strongly bound symbols were present in target MacOS SDK versions was failing.
Strangely, the failure was only occurring on LTO optimized (either the
lto
orpgo+lto
optimization level) builds of CPython 3.10 or newer. Not 3.8 or 3.9. Nor any non-LTO build configuration on 3.10+.The most likely symbols to be strongly bound instead of weak are
mknodat
andmkfifoat
. However, pretty much every CPython weakly bound symbol is affected once the MacOS SDK is upgraded. (PR #161 suggested disablingmknodat
andmkfifoat
globally as a workaround but it turns out this problem is beyond those two symbols.)The text was updated successfully, but these errors were encountered: