Rustのdoctestには$ORT_OUT_DIRのハックが効かない

[qryxip]

不具合の内容

Rustのdoctestには #223 の対策が効かないので、WindowsではC:\Windows\System32\onnxruntime.dllが解決されてしまう。

#427 で解決されると思われる。

現象・ログ

割愛

再現手順

ORTを読み込む何かしらのdoctestを書き、Windows上で実行

期待動作

コケない

VOICEVOXのバージョン

N/A

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

• Windows
• macOS
• Linux

macOSやLinuxでも、古いonnxruntimeがあるとそっちが解決されうるかもしれない。

その他

ワークアラウンド: https://github.com/VOICEVOX/voicevox_core/pull/532/files#r1257178769

[Hiroshiba]

この現象、結構不便ですよね･･･。

そういえば、いつか聞いたかもしれないのですが、そもそも製品エンジンのrun.exeはなぜ正しいonnxruntime.dllを参照できるんでしょう。
同じディレクトリにあるから･･･････？

あと #427 で解決されると思われるロジックも知見のために知りたいかもです！
dllを作らないからとかでしょうか。

[qryxip]

そもそも製品エンジンのrun.exeはなぜ正しいonnxruntime.dllを参照できるんでしょう。
同じディレクトリにあるから･･･････？

ですね。

#427 で解決されると思われるロジック

bindgenの dynamic-loadingというオプションによってonnxruntime.dllの読み込みが dlopen/LoadLibrary*ベースになっているため、バイナリ起動後に関数の引数とかでDLLを読めるようになるからですね。

その #427 ですが、 microsoft/onnxruntime#12606 以降Rustバインディングの音沙汰が無いので、いっそのことVOICEVOX/onnxruntime-rsをdynamic-loadingにした方がいいかもしれません。bindgenのオプションを設定した上で手直しすることになるのですが、案外手間は少いかもしれません。

参考: rust-bindgen で手軽に共有ライブラリを動的読み込み - OPTiM TECH BLOG

[Hiroshiba]

なるほどです！

microsoftの方がどうやってdynamic loadingしてるのかわかりませんが、この辺りですかね？
https://github.com/microsoft/onnxruntime/pull/12606/files#diff-a8903875d7a7d401f09518758fe7c764b68f3d8360f4ba30484384d69569a315R91

たしかに本家onnxruntime-rsはやってないように見えます。
https://github.com/nbigaouette/onnxruntime-rs/blob/31f62235e3048390fa1aba67fa6316ed90a628d7/onnxruntime-sys/build.rs#L100

簡単に実現できるなら手を入れても良さそうだなと感じました！