You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Summary:
TL;DR: We need to make sure the runtime so deps is the same as compile time so library. We can't build the so from source, because runtime uses another one.
Instead of importing fbjni repo into executorch, and building from executorch as a subdir, we need to use a pre-built (on maven repo) fbjni.so together with its headers. We need to link our executorch JNI library against that fbjni.so. We can't link against fbjni as a static library, because the Java layer needs to load it, and we can't have duplicated symbol from static and shared lib.
For Android apk developer, they need to import executorch as AAR, as well as fbjni AAR from maven. Inside fbjni AAR, we don't know which NDK is the fbjni.so built. If the NDK version between executorch and fbjni is different, we may have incompatible c++ library. This caused issues like
```
java.lang.UnsatisfiedLinkError: dlopen failed: cannot locate symbol "_ZTVNSt6__ndk114basic_ifstreamIcNS_11char_traitsIcEEEE" referenced by "/data/app/~~enBXzd5mY8qQNSRdnGW4vg==/com.example.executorchllamademo-u8anctHQVTL1jVJsZsEqRQ==/lib/arm64/libexecutorch.so"...
```
in the past.
Therefore, we need to always make sure we have a specific fbjni version for a given executorch release (say 0.5.1 for 20241010). We download the AAR from maven, which provides "prefab" artifacts, including the so library and header for us to compile ET jni code.
With this change, we can build ET JNI with any NDK version, regardless of how fbjni built their library.
Pull Request resolved: #6163
Reviewed By: larryliu0820
Differential Revision: D64249736
Pulled By: kirklandsign
fbshipit-source-id: 0e415d6f1780ef35253507899366d302df80c82b
0 commit comments