Skip to content

Platform builds

The table

GOOS/GOARCH Archive Library taken out
linux/amd64 onnxruntime-linux-x64-<v>.tgz libonnxruntime.so.<v>
linux/arm64 onnxruntime-linux-aarch64-<v>.tgz libonnxruntime.so.<v>
darwin/arm64 onnxruntime-osx-arm64-<v>.tgz libonnxruntime.<v>.dylib
darwin/amd64 onnxruntime-osx-x86_64-<v>.tgz libonnxruntime.<v>.dylib

Anything not listed raises ErrNoPlatformBuild. Windows is absent because no consumer needed it, not because it could not be added — a row here and a published archive is the whole change.

What the extracted file is called

Platform Name on disk
Linux libonnxruntime.so
macOS libonnxruntime.dylib

Unversioned, because that is what a library bundled beside an executable is called and what a caller passing an explicit path would point at. The version is carried in the cache directory instead, so two versions coexist.

The names are only names

This table says what each platform's archive is called. Whether the channel carries it at a given version is the channel's business — asking for one that is not published is an ordinary not-found from go/artifacts, not something this table needs to duplicate and keep in step.

That distinction matters because upstream availability changes. macOS Intel was published up to 1.23.0 and dropped by 1.26.0. The row stays; the archive stops existing at some versions; the error a caller sees is "not found for this version" rather than "unsupported platform", which is the true statement.

Both errors name the same remedy — an explicit library path — because they are one situation arriving two ways, and a reader should not get a less useful error depending on which way they hit it.

The archives contain several entries whose names end the same way: the real shared object, one or more symlinks beside it, and libonnxruntime_providers_shared.so. The lib column names the versioned regular file, and non-regular entries are skipped during extraction — so a symlink matching the name is passed over rather than followed.