-
Notifications
You must be signed in to change notification settings - Fork 13.3k
constructor doesn't work with arm64e-apple-ios but works on arm64e-apple-darwin #139218
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
Comments
The issue here probably arises from #133832, though I'm pretty sure what we're doing there is correct, the symbol relocations that we're emitting are what's needed for the newer arm64e ABI - the problem is that the rest of I guess we could fix this (and #138481) by not special-casing arm64e in @rustbot label -needs-triage +O-apple +A-linkage A-llvm O-AArch64 |
So I did some more digging the first issue on a clean build is due to building the build.rs for a dependency while SDKROOT is set and therefore it builds the build.rs which is meant to run on the host with the targets sysroot (unsure if there is a proper workaround for this) but building for arm64e-apple-darwin then for arm64e-apple-ios seems to work alright. @madsmtm as for the second issue, I dont think the issues you mentioned are related. If i do a clean build targeting arm64e-apple-darwin it builds completely fine, but for arm64e-apple-ios i get this symbol not assigned an address error. The issues you linked are specific to arm64e but not darwin vs ios. For me darwin works correctly so it must be some difference with ios and darwin in rust. Any ideas why the darwin one works but not ios? regarding using aarch64 i am looking to inject my dylib into a process which is arm64e which requires the library being injected to also be arm64e, im not too worried if the rust code once running is actually doing pointer auth things. |
Linker warnings are suppressed on Apple platforms. You likely still get the same warning and maybe it just falls back to building a non-arm64e dylib? |
Ah, yeah, that's caused by #80817.
Hmm, no, a guess could be that the linker is more restrictive on iOS? Or that LLVM's codegen is slightly different there? @rustbot label O-ios |
checked with
too bad. might just put this project on the back burner for now. i really appreciate all the work you and others are putting in on the apple ecosystem, its pretty fun to work with rust and apple devices |
If you're up for compiling diff --git i/compiler/rustc_codegen_ssa/src/back/apple.rs w/compiler/rustc_codegen_ssa/src/back/apple.rs
index 2c8b0ec418d..c32b73ae34f 100644
--- i/compiler/rustc_codegen_ssa/src/back/apple.rs
+++ w/compiler/rustc_codegen_ssa/src/back/apple.rs
@@ -88,7 +88,7 @@ pub(super) fn add_data_and_relocation(
kind: SymbolExportKind,
) -> object::write::Result<()> {
let authenticated_pointer =
- kind == SymbolExportKind::Text && target.llvm_target.starts_with("arm64e");
+ kind == SymbolExportKind::Text && target.llvm_target.starts_with("arm64e") && false;
let data: &[u8] = match target.pointer_width {
_ if authenticated_pointer => &[0, 0, 0, 0, 0, 0, 0, 0x80], Alternatively, use an older nightly ( |
I am compiling a dylib targeting arm64e for macos and ios. I am using the ctor crate (https://crates.io/crates/ctor) but also ruled that out by just using the expanded code (cargo expand).
my .cargo/config.toml (using xcode14 clang to allow linking arm64e):
my lib.rs:
for macos i use:
cargo +nightly build -Z build-std --target arm64e-apple-darwin
for ios i use:
SDKROOT=~/Documents/ios_sdks/iPhoneOS16.0.sdk cargo +nightly build -Z build-std --target arm64e-apple-ios
when compiling this code for ios i get the error with a clean build:
This error seems like something is confused and wants to build macos?
building macos then ios:
This error just seems like the symbol for the constructor is getting removed
Meta
rustc --version --verbose
:The text was updated successfully, but these errors were encountered: