piper: Build fails with onnxruntime 1.13.1

Hi, wanted to check out larynx2 through nixpkgs and noticed that it doesn’t compile with onnxruntime 1.13.1, but works with 1.12.1. Just a heads up.

larnyx> [ 50%] Building CXX object CMakeFiles/larynx.dir/main.cpp.o
larnyx> In file included from /build/source/src/cpp/larynx.hpp:13,
larnyx>                  from /build/source/src/cpp/main.cpp:15:
larnyx> /build/source/src/cpp/model.hpp: In function 'void larynx::loadModel(std::string, larynx::ModelSession&)':
larnyx> /build/source/src/cpp/model.hpp:57:22: error: 'struct Ort::Session' has no member named 'GetInputName'
larnyx>    57 |         session.onnx.GetInputName(i, session.allocator));
larnyx>       |                      ^~~~~~~~~~~~
larnyx> /build/source/src/cpp/model.hpp:62:22: error: 'struct Ort::Session' has no member named 'GetOutputName'
larnyx>    62 |         session.onnx.GetOutputName(i, session.allocator));
larnyx>       |                      ^~~~~~~~~~~~~
larnyx> make[2]: *** [CMakeFiles/larynx.dir/build.make:76: CMakeFiles/larynx.dir/main.cpp.o] Error 1
larnyx> make[1]: *** [CMakeFiles/Makefile2:83: CMakeFiles/larynx.dir/all] Error 2
larnyx> make: *** [Makefile:91: all] Error 2

Am I correct to assume that the models are tied to the onnxruntime version?

About this issue

Original URL
State: closed
Created a year ago
Comments: 21 (9 by maintainers)

Most upvoted comments

Also, thank you for packaging this up 🙂

synesthesiam on Jan 14, 2023

2 options here that come to my mind:

If you want container images that stand by them-self but are still able to share common packages with other containers, you can use docker abstraction in nixpkgs (https://nix.dev/tutorials/building-and-running-docker-images, there is also https://github.com/nlewo/nix2container). This will more or less put packages in its own filesystem layer.
To make a writeable store work, what you are describing to work, you would have one container that has a nix-daemon and its socket is mounted into other containers. Each container could than do something like nix-store -r some/store/path that pulls from a binary cache.

I think option 1. better explored and you may want to start with that. I have used something like option 2 but in my case the nix-daemon was simply installed into the host.

Or maybe I got you wrong and you just want one container with nix and stores all its files outside? Maybe you can elaborate what features and goals you are trying to achieve with this setup - I now the nix code daemon code and container namespaces in a general a bit, so I might have an idea what problems you might face.

Mic92 on Jan 16, 2023