ONNX Runtimeのリンクをdlopen/LoadLibraryベースにする

[qryxip]

内容

ONNX Runtimeのリンクをdlopen/LoadLibraryベースにします。

Pros 良くなる点

以下のような問題が解決される。

• voicevox_core python api - dll loading - windows #445
• APIの名称や案内をする時のルールを列挙してドキュメント化する #543
• ダウンローダーにcore.zip以外だけをダウンロードする機能を持たせる #642
• Windowsデフォルトのonnxruntimeが使われた時に気付けるようにしたい #644

Cons 悪くなる点

実現方法

#718 をしたときにdlopen/LoadLibraryモードに切り替える。ただし現状のVOICEVOX/onnxruntime-rsでも可能ではある。

VOICEVOXのバージョン

N/A

OSの種類/ディストリ/バージョン

• Windows
• macOS
• Linux

その他

実行に移すタイミング次第では以下のようなissueに影響が出ると思います。

• manylinuxを使えるようにする #691 (CC: @tuna2134)
• iOS版でApp Storeにサブミットすると問題がありと指摘され受取拒否される。 #715 (CC: @nekomimimi) (iOSだけ従来通りのリンク、または静的リンクという手はあると思います)

[nekomimimi]

動的ライブラリをframeworkで包む版、現状、スクリプトを書き終わって1.15.1でxcframeworkができるようになって1.14.1で確認しようと思って作成すると手前の処理で落ちて、動作確認のテストできない状況です。

作ってみて思うのは、
1.空のframeworkの雛形を使う実装なので問題のないもののちょっと不自然
2.rpathの指定などが入り複雑になってメンテナンスが静的リンクより大変そう。
と思います。

iOS版は動的リンクに大きなメリットがなければ、静的リンクなどの方がシンプルで簡単な気がします。

一旦作業は止めて、必要があれば再開します。

[Hiroshiba]

基本的にはdlopenの形に賛成です！
普通はどっちにするのが一般的かわかりませんが、動的リンクだと実行時にエラーの理由を出せないのがやっぱりつらい･･･ 😇

@qryxip
動的リンクとdlopenをビルド時に切り替える、ということはまあまあ容易にできそうだったりしますか？ 👀
であれば @nekomimimi さんのタスクはこのissueを特に気にすることなく進められるのかなと思った次第です！

[qryxip]

featureのオンオフで切り替え可能だと思います(静的リンクも含め)。

[Hiroshiba]

なるほどです、ありがとうございます！！
であればたぶん、こちらのissueを進める場合も、 @nekomimimi さんの手を止めてしまうことなく動けるの感じなのかなと思いました！

[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に変えてだいたいは動きそうな気がします。

[Hiroshiba]

@nekomimimi ５ですね！　あ、６のがより近いかもです。

より正確に言うと、そもそもonnxruntimeは公式には動的ライブラリしか配布していないので、iOS版だけ静的リンクにしたり、全環境の静的リンク版を作るよりは合わせた方が管理が楽だったという感じです！

[nekomimimi]

了解です。そのままdylibをframeworkで包む方針でいきます！