bridge: only use cpufeatures on iOS #565
Conversation
|
I have signed the agreement now. |
|
What's the motivation for making this change? This isn't the only dependency on cpufeatures in the workspace; it's just setting a minimum version before where Apple aarch64 CPUs weren't correctly considered as having unconditional support for…something, I forget what. |
|
I am the maintainer of the mautrix-signal package for Alpine Linux, which depends on libsignal. We build for many architectures, but some of them, such as riscv64 and ppc64le, are being blocked by the cpufeatures crate, since it doesn't support those architectures.
This is true, however, the ones that do only use them on architectures that support it, see: https://lib.rs/crates/sha1 |
|
A fair point. Obligatory "Signal the organization doesn't support third-party clients and use with a bridge" and "libsignal the library doesn't support direct use of the entry points in libsignal-ffi (they are even more subject to change than the non-bridge Rust crates and the Swift API built on top of them)". You didn't quite get the iOS triple right, but we can take care of that. |
All good 👍
Really? |
|
That's an iOS triple, but not the normal one, which is just aarch64-apple-ios. arm64e is the experimental variant that enables pointer tagging checks, which Apple hasn't finalized the ABI for. |
|
Thanks for pointing that out, it is now fixed. 👍 |
|
Included in v0.42.0! |
The
cpufeaturescrate only supports a limited number of architectures, and since a comment explicitly stated that this is for iOS optimization, and since the same is done for jni, I think this is a sensible change.