Adopt the upstream split-backend linking once executorch#21849 lands
メンテナーはふだん 1 日以内に返信
まだ誰も着手していません。
評価
この issue はまだ評価されていません。
説明
Once pytorch/executorch#21849 lands, move RNE to an ExecuTorch release that carries it and adopt the supported arrangement rather than the one we build today.
Why this needs a deliberate step
We already ship split backend .so files, but our libs are built from the PR branch and the topology we rely on is not the one the upstream AAR uses. Ours works because libRnExecutorch.so links libexecutorch.so and the backend together, so they land in one lookup group with the runtime first. The shipped v0.10.2-libs backends confirm the dependency is implicit:
libxnnpack_executorch_backend.so NEEDED: libm, liblog, libdl, libc # no libexecutorch
GLOBAL DEFAULT executorch::runtime::register_backend(...) # its own copy
The merged version links the backend against the runtime instead, so register_backend and get_pthreadpool become UND and resolve through DT_NEEDED. That is load-order independent, and libexecutorch.so gains a matching SONAME.
What to check when we bump
-
android/CMakeLists.txtstill links the backends explicitly. WithDT_NEEDEDin place this is no longer what makes registration work, but it is still what gets them packaged. - Confirm the new backends are
UNDforregister_backend, not defining it:llvm-readelf --dyn-syms libxnnpack_executorch_backend.so | grep register_backend. - Confirm
DT_NEEDEDnameslibexecutorch.soand that theSONAMEof our staged runtime matches, or the loader looks for a file the APK does not carry. - Re-check the thread pool:
get_pthreadpool()must resolve to the runtime's singleton, otherwise XNNPACK runs on a second, unconfigured pool and our thread-count tuning silently does nothing. - Run a delegated model on device per backend. A backend registering into the wrong table fails as
DelegateNotFoundat execution, not at load, so a smoke test that only loads the library will not catch it.
Related
- Upstream PR: pytorch/executorch#21849
- Our current libs:
v0.10.2-libs
- 主要言語
- TypeScript
- スター
- 1.8k
- フォーク
- 101
- 平均マージ
- 2日 4時間
- マージ済み PR（30日）
- 58
環境構築
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートあり
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
software-mansion/react-native-executorch のほかの issue
-
dependencies platform: ios
難易度 1/5 1〜3時間 初心者へのやさしさ 78/100
software-mansion/react-native-executorch#1617 ·
メンテナーはふだん 1 日以内に返信
-
Peer react-native >=0.83対応中かも @msluszniak が今日担当しました。 オープンdependencies dev exp
難易度 1/5 1時間未満 初心者へのやさしさ 25/100
software-mansion/react-native-executorch#1623 ·
メンテナーはふだん 1 日以内に返信
-
Docs: iOS < 17 fails pod install on the bare template対応中かも @msluszniak が今日担当しました。 オープンdocumentation platform: ios
難易度 1/5 1時間未満 初心者へのやさしさ 20/100
software-mansion/react-native-executorch#1622 ·
メンテナーはふだん 1 日以内に返信
-
Docs: dynamic frameworks are supported対応中かも @msluszniak が今日担当しました。 オープンdocumentation platform: ios
難易度 1/5 1〜3時間 初心者へのやさしさ 35/100
software-mansion/react-native-executorch#1621 ·
メンテナーはふだん 1 日以内に返信
-
Docs: drop the Expo babel.config.js step対応中かも @msluszniak が今日担当しました。 オープンdocumentation
難易度 1/5 1時間未満 初心者へのやさしさ 25/100
software-mansion/react-native-executorch#1620 ·
メンテナーはふだん 1 日以内に返信
software-mansion/react-native-executorch の issue をすべて見る
似ている issue
-
test-reliability
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
Azure/azure-sdk-for-js#40672 · リアクション 1 件 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 74/100
HarperFast/studio#2067 ·
メンテナーはふだん 2 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 65/100
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
メンテナーはふだん 1 日以内に返信
-
documentation
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
liberation-data/drivine#639 · コメント 2 件 ·
メンテナーはふだん 1 日以内に返信