Some libraries built for x86_64 fail at runtime lacking __extenddftf2 symbol

[jmartinesp]

While building with the latest cargo-ndk version and NDK r25, libs for all architectures build fine, but on our x86_64 emulators our Android app crashes instantly when started because it can't find the __extenddftf2 symbol:

04-12 21:45:22.118 E/AndroidRuntime( 9230): Process: io.element.android.x.debug, PID: 9230
04-12 21:45:22.118 E/AndroidRuntime( 9230): java.lang.RuntimeException: Unable to create application io.element.android.x.ElementXApplication: androidx.startup.StartupException: java.lang.UnsatisfiedLinkError: Unable to load library 'matrix_sdk_ffi':
04-12 21:45:22.118 E/AndroidRuntime( 9230): dlopen failed: cannot locate symbol "__extenddftf2" referenced by "/data/app/~~_fl7RirpC9FRkAXTX8yEeA==/io.element.android.x.debug-o6Z0kMjlRtOv9LzqMyA3Tg==/base.apk!/lib/x86_64/libmatrix_sdk_ffi.so"...
04-12 21:45:22.118 E/AndroidRuntime( 9230): dlopen failed: cannot locate symbol "__extenddftf2" referenced by "/data/app/~~_fl7RirpC9FRkAXTX8yEeA==/io.element.android.x.debug-o6Z0kMjlRtOv9LzqMyA3Tg==/base.apk!/lib/x86_64/libmatrix_sdk_ffi.so"...
04-12 21:45:22.118 E/AndroidRuntime( 9230): dlopen failed: cannot locate symbol "__extenddftf2" referenced by "/data/app/~~_fl7RirpC9FRkAXTX8yEeA==/io.element.android.x.debug-o6Z0kMjlRtOv9LzqMyA3Tg==/base.apk!/lib/x86_64/libmatrix_sdk_ffi.so"...
04-12 21:45:22.118 E/AndroidRuntime( 9230): Native library (android-x86-64/libmatrix_sdk_ffi.so) not found in resource path (.)

This seems quite similar to what was fixed in this Mozilla repo, although if I'm not mistaken you took a different approach that was later removed here (maybe this workaround was for a whole different issue though).

Would it be possible to either restore this workaround or find another way to fix this issue? It's preventing us from running UI tests on our apps since all our CI emulators are x86_64 and the apps won't even start, but it will also mean our app will be broken in x86_64 devices (although hopefully there won't be many of those).

Thank you, and sorry if I'm lacking some details or maybe I misunderstood something about this issue: I'm more of an Android-only developer and I don't have much experience with Rust and the NDK.

[jmartinesp]

As linked above, I was able to find a workaround by using an old version of cargo-ndk and NDK r22b. It's not ideal, but it might be enough until the root issue is fixed in case no one has time to implement a better workaround.

[bbqsrc]

@jmartinesp the Mozilla solution can work here, and would be happy to have a PR implementing it.

Alternatively, throw a sponsorship my way and I can prioritise it within this week.

[jmartinesp]

@jmartinesp the Mozilla solution can work here, and would be happy to have a PR implementing it.

I'd love to, but I have very limited knowledge of the cargo tooling, so don't know how to do that 😅 . We ended up implementing it in our codebase, as that's quite simpler, we just need to follow the same workaround added above in our build.rs file.

Anyway, thanks for your work in this tool, it's been really useful to us so far! Feel free to close the issue if you think it's not something worth working on, as it might get fixed in the Rust compiler, which seems to be the root cause of the issue.

[bbqsrc]

While linking to the builtins may be required by a decent number of crates (sqlite comes to mind for handling weird float sizes, unless that crate is updated with Android-specific handling), it's not something I think I want to integrate into cargo-ndk by default.

If somebody wants to add this, introducing a --link-builtins flag to do so would be my suggestion.