Bundle a runtime with your binary¶

You are shipping a packaged application and want the runtime to travel with it, so a first run works with no network.

Put it beside the executable¶

Name it exactly:

/opt/yourtool/
├── yourtool
└── libonnxruntime.so

The resolver looks in the directory of os.Executable(), finds it, and never touches the cache or the network.

The name is unversioned because that is what a bundled library is called. The version lives in the cache path instead, which is what lets two versions coexist there without colliding.

Extract one from the channel to bundle¶

The resolver's own cache is the easiest source: resolve once on a machine of the target platform, then copy what it returns.

$ go run ./cmd/resolve-runtime
runtime at: /home/you/.cache/phpboyscout/onnxruntime/1.28.0/libonnxruntime.so
$ cp /home/you/.cache/phpboyscout/onnxruntime/1.28.0/libonnxruntime.so dist/

Those bytes were signature- and digest-verified on the way in, so what you are bundling is what the publisher signed.

Cross-building for another platform¶

WithPlatform selects the archive for a platform other than the one you are on, which is how one build host populates several distributions:

resolver, err := onnxruntime.New(client,
    onnxruntime.WithPlatform("darwin/arm64"),
    onnxruntime.WithCacheDir("dist/darwin-arm64"))

The extracted file is named for the target platform, so the macOS build gets a .dylib even when the machine doing the extracting runs Linux.

Tell the resolver where the executable is¶

Under go test, or anywhere the binary is not where the payload is, WithExecutableDir overrides the search directory:

onnxruntime.New(client, onnxruntime.WithExecutableDir("/opt/yourtool"))