Issue with Loading Native Library 'uniffi_xmtpv3' on Android

[stranger11]

Describe the bug

I encountered a fatal exception with the following error message: java.lang.UnsatisfiedLinkError: Unable to load library 'uniffi_xmtpv3': Native library (android-x86/libuniffi_xmtpv3.so) not found in resource path (.) It seems that the native library 'uniffi_xmtpv3' is not being loaded properly on Android. The error points to a failure in locating the native library file. Additionally, there are suppressed exceptions indicating problems with symbol referencing and library extraction.

This issue occurs during the initialization of the application and prevents it from functioning correctly. It seems to be related to the absence of the '__atomic_is_lock_free' symbol in the referenced libraries.

Expected behavior

The native library 'uniffi_xmtpv3' should be loaded successfully without any errors.

Steps to reproduce the bug

1)Run the application on emulator with intel x86. 2)Observe the fatal exception reported in the log.

[rsappelit]

Faced this error on Emulator Only

Code : Client().create(key, clientOptions)

Error Logs :

16:40:10.932 E FATAL EXCEPTION: main Process: com.qriptos.app.dev, PID: 8181 java.lang.UnsatisfiedLinkError: Unable to load library 'uniffi_xmtpv3': dlopen failed: cannot locate symbol "extenddftf2" referenced by "/data/app/~~uAifSHQOHILLo_gR3FSrqg==/com.qriptos.app.dev-fpJPyYt6ba31WRaM4z9qWg==/base.apk!/lib/x86_64/libuniffi_xmtpv3.so"... dlopen failed: cannot locate symbol "__extenddftf2" referenced by "/data/app/~~uAifSHQOHILLo_gR3FSrqg==/com.qriptos.app.dev-fpJPyYt6ba31WRaM4z9qWg==/base.apk!/lib/x86_64/libuniffi_xmtpv3.so"... dlopen failed: cannot locate symbol "extenddftf2" referenced by "/data/app/~~uAifSHQOHILLo_gR3FSrqg==/com.qriptos.app.dev-fpJPyYt6ba31WRaM4z9qWg==/base.apk!/lib/x86_64/libuniffi_xmtpv3.so"... Native library (android-x86-64/libuniffi_xmtpv3.so) not found in resource path (.) at com.sun.jna.NativeLibrary.loadLibrary(NativeLibrary.java:323) at com.sun.jna.NativeLibrary.getInstance(NativeLibrary.java:483) at com.sun.jna.Library$Handler.(Library.java:197) at com.sun.jna.Native.load(Native.java:622) at com.sun.jna.Native.load(Native.java:596) at uniffi.xmtpv3._UniFFILib$Companion$INSTANCE$2.invoke(xmtpv3.kt:3965) at uniffi.xmtpv3._UniFFILib$Companion$INSTANCE$2.invoke(xmtpv3.kt:382) at kotlin.SynchronizedLazyImpl.getValue(LazyJVM.kt:74) at uniffi.xmtpv3._UniFFILib$Companion.getINSTANCE$library_release(xmtpv3.kt:382) at uniffi.xmtpv3.Xmtpv3Kt.getVersionInfo(xmtpv3.kt:3880) at org.xmtp.android.library.Client.(Client.kt:88) at com.qriptos.app.core.data.network.xmtp.XMTPManager$setupXMTP$2.invokeSuspend(XMTPManager.kt:121) at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33) at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:108) at kotlinx.coroutines.internal.LimitedDispatcher$Worker.run(LimitedDispatcher.kt:115) at kotlinx.coroutines.scheduling.TaskImpl.run(Tasks.kt:103) at kotlinx.coroutines.scheduling.CoroutineScheduler.runSafely(CoroutineScheduler.kt:584) at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.executeTask(CoroutineScheduler.kt:793) at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.runWorker(CoroutineScheduler.kt:697) at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run(CoroutineScheduler.kt:684) Suppressed: java.lang.UnsatisfiedLinkError: dlopen failed: cannot locate symbol "extenddftf2" referenced by "/data/app/~~uAifSHQOHILLo_gR3FSrqg==/com.qriptos.app.dev-fpJPyYt6ba31WRaM4z9qWg==/base.apk!/lib/x86_64/libuniffi_xmtpv3.so"... at com.sun.jna.Native.open(Native Method) at com.sun.jna.NativeLibrary.loadLibrary(NativeLibrary.java:211) ... 19 more Suppressed: java.lang.UnsatisfiedLinkError: dlopen failed: cannot locate symbol "__extenddftf2" referenced by "/data/app/~~uAifSHQOHILLo_gR3FSrqg==/com.qriptos.app.dev-fpJPyYt6ba31WRaM4z9qWg==/base.apk!/lib/x86_64/libuniffi_xmtpv3.so"... at com.sun.jna.Native.open(Native Method) at com.sun.jna.NativeLibrary.loadLibrary(NativeLibrary.java:224) ... 19 more Suppressed: java.lang.UnsatisfiedLinkError: dlopen failed: cannot locate symbol "extenddftf2" referenced by "/data/app/~~uAifSHQOHILLo_gR3FSrqg==/com.qriptos.app.dev-fpJPyYt6ba31WRaM4z9qWg==/base.apk!/lib/x86_64/libuniffi_xmtpv3.so"... at java.lang.Runtime.loadLibrary0(Runtime.java:1077) at java.lang.Runtime.loadLibrary0(Runtime.java:998) at java.lang.System.loadLibrary(System.java:1656) at com.sun.jna.NativeLibrary.loadLibrary(NativeLibrary.java:238) ... 19 more Suppressed: java.io.IOException: Native library (android-x86-64/libuniffi_xmtpv3.so) not found in resource path (.) at com.sun.jna.Native.extractFromResourcePath(Native.java:1145) at com.sun.jna.NativeLibrary.loadLibrary(NativeLibrary.java:295) ... 19 more Suppressed: kotlinx.coroutines.internal.DiagnosticCoroutineContextException: [StandaloneCoroutine{Cancelling}@5bf2a5d, Dispatchers.Main.immediate]

[tuddman]

I've done some more digging. We are experiencing this issue because OpenSSL, using certain Zig toolchains in various CI buildsteps, is being built without correct Atomics support. This problem has been discussed in multiple places, including the Rust Cargo issue #13546, OpenSSL issue #23376, and the comment thread on OpenSSL pull request #20927.

The core of the problem is that the OpenSSL library, when built without proper atomics support, makes subsequent artifacts : uniffi_xmtpv3 , that is built using it also won't have proper Atomics support. Hence the errors we see above. This is not resolved by simply changing the OpenSSL version in sfackler/rust-openssl/releases nor maintaining a pinned version as was done https://github.com/xmtp/libxmtp/pull/709

An Option

Build OpenSSL directly with the necessary flag to enable Atomics support. Specifically, the flag -DBROKEN_CLANG_ATOMICS

args += ["-DBROKEN_CLANG_ATOMICS"]

By including this flag, we at least ensure that OpenSSL is built with the correct support for Atomics, which should resolve this. The downside is that manually compiling openssl everytime will significantly slow our CI.

One other thing to try would be, as a part of the build environment, to set the env var OPENSSL_STATIC which if set, the crate will statically link to OpenSSL rather than dynamically link.

[nplasterer]

One other thing to try would be, as a part of the build environment, to set the env var OPENSSL_STATIC which if set, the crate will statically link to OpenSSL rather than dynamically link.

Have you tried this? If we can make that work that would probably be the most ideal. Unfortunately we can't use warp builds to speed up CI for this since the open source Github actions are the only Ubuntu ones that KVM.