Use fbjni from maven #6163
Use fbjni from maven #6163
Conversation
🔗 Helpful Links🧪 See artifacts and rendered test results at hud.pytorch.org/pr/pytorch/executorch/6163
Note: Links to docs will display an error until the docs builds have been completed. ✅ You can merge normally! (1 Unrelated Failure)As of commit 96e380f with merge base 56a3d1e ( BROKEN TRUNK - The following job failed but were present on the merge base:👉 Rebase onto the `viable/strict` branch to avoid these failures
This comment was automatically generated by Dr. CI and updates every 15 minutes. |
facebook-github-bot
added
the
CLA Signed
|
@kirklandsign has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator. |
| endif() | ||
|
|
||
| set(FBJNI_AAR_URL https://repo1.maven.org/maven2/com/facebook/fbjni/fbjni/${FBJNI_VERSION}/fbjni-${FBJNI_VERSION}.aar) | ||
| set(FBJNI_DOWNLOAD_PATH ${CMAKE_CURRENT_BINARY_DIR}/third-party/fbjni/fbjni.aar) |
There was a problem hiding this comment.
This seems risky? How do you make sure things under third-party/fbjni is compatible with fbjni.aar downloaded from Maven?
There was a problem hiding this comment.
Sorry I need to remove examples/third-party/fbjni in a follow up PR. We can't use it. 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. The fbjni.aar downloaded from Maven basically contains a "SDK" of headers and so library for us to link our ET library against.
We should use the library from maven repo
|
@kirklandsign has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator. |
|
@kirklandsign merged this pull request in 61c501c. |
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
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.