Closed qryxip closed 1 month ago
動的ライブラリをframeworkで包む版、現状、スクリプトを書き終わって1.15.1でxcframeworkができるようになって1.14.1で確認しようと思って作成すると手前の処理で落ちて、動作確認のテストできない状況です。
作ってみて思うのは、 1.空のframeworkの雛形を使う実装なので問題のないもののちょっと不自然 2.rpathの指定などが入り複雑になってメンテナンスが静的リンクより大変そう。 と思います。
iOS版は動的リンクに大きなメリットがなければ、静的リンクなどの方がシンプルで簡単な気がします。
一旦作業は止めて、必要があれば再開します。
基本的にはdlopenの形に賛成です! 普通はどっちにするのが一般的かわかりませんが、動的リンクだと実行時にエラーの理由を出せないのがやっぱりつらい・・・ 😇
@qryxip
動的リンクとdlopen
をビルド時に切り替える、ということはまあまあ容易にできそうだったりしますか? 👀
であれば @nekomimimi さんのタスクはこのissueを特に気にすることなく進められるのかなと思った次第です!
featureのオンオフで切り替え可能だと思います(静的リンクも含め)。
なるほどです、ありがとうございます!! であればたぶん、こちらのissueを進める場合も、 @nekomimimi さんの手を止めてしまうことなく動けるの感じなのかなと思いました!
@Hiroshiba 一点、教えていただきたい事がありまして、 iOS版について静的リンク(.a)より現状の動的リンク(.dylib)にしたい理由をお教えください。 これらのうちのどれかかなと想像しました。
1.voicevox_coreと関数名の被る別のライブラリを同時に使うアプリが想定される。 2.複数のバージョンのonnixruntimeを同時に使うアプリが想定される。 3.onnixruntimeとvoicevox_coreのバージョンが合わない時にクラッシュさせたい。 4.パフォーマンスの問題。 5.静的ライブラリにすると作成の作業時間がかかりそう。 6.その他
自分の感覚的には 1.と2.が理由にあれば動的ライブラリの方が将来対応しやすそう。 3.よく複数ライブラリに分かれてることはあるけどclashしない場合があっても問題なく、.aで十分(あまり間違えない) 4.よく知らない。 5.rust側がわかりませんが、deploy手前の加工は今のスクリプトのdylibを.aに変えてだいたいは動きそうな気がします。
@nekomimimi 5ですね! あ、6のがより近いかもです。
より正確に言うと、そもそもonnxruntimeは公式には動的ライブラリしか配布していないので、iOS版だけ静的リンクにしたり、全環境の静的リンク版を作るよりは合わせた方が管理が楽だったという感じです!
了解です。そのままdylibをframeworkで包む方針でいきます!
内容
ONNX Runtimeのリンクを
dlopen
/LoadLibrary
ベースにします。Pros 良くなる点
以下のような問題が解決される。
445
543
642
644
Cons 悪くなる点
実現方法
718 をしたときに
dlopen
/LoadLibrary
モードに切り替える。ただし現状のVOICEVOX/onnxruntime-rsでも可能ではある。VOICEVOXのバージョン
N/A
OSの種類/ディストリ/バージョン
その他
実行に移すタイミング次第では以下のようなissueに影響が出ると思います。
691 (CC: @tuna2134)
715 (CC: @nekomimimi) (iOSだけ従来通りのリンク、または静的リンクという手はあると思います)