Summary

Since 0.12.0 removed ort-load-dynamic from the default embedding-fastembed build (#50), the statically-linked ONNX Runtime archive breaks consumer release builds on Linux and Windows. A downstream crate that ships a dist/cargo build --release artifact can no longer link llm-kernel >= 0.12.0 on stock CI runners without opting into the dynamic-linking escape hatch.

This is the downstream cost of the fix for #50 — documenting it here so other consumers don't trip over it, and to discuss whether the default should change.

Reproduction (downstream: alcove)

alcove pins llm-kernel and builds release artifacts via cargo-dist for 4 targets. Upgrading llm-kernel 0.9.2 → 0.14.0 makes 3 of 4 release builds fail at the link step (cargo check stays green because it doesn't link):

Linux (ubuntu-22.04, glibc 2.35, x86_64-unknown-linux-gnu / aarch64-unknown-linux-gnu):

error: linking with `cc` failed: exit status: 1
  = note: rust-lld: error: undefined symbol: __isoc23_strtoll
          rust-lld: error: undefined symbol: __isoc23_strtoull
          rust-lld: error: undefined symbol: __isoc23_strtol
          collect2: error: ld returned 1 exit status

The static ort archive references glibc 2.38+ symbols. ubuntu-22.04 ships glibc 2.35.

Windows (windows-latest, x86_64-pc-windows-msvc):

libort_sys-*.rlib(io_win32.obj) : error LNK2019: unresolved external symbol __imp__wsopen_dispatch ...
libort_sys-*.rlib(io_win32.obj) : error LNK2019: unresolved external symbol __imp__wstat64i32 ...
libort_sys-*.rlib(softmax_shared.obj) : error LNK2019: unresolved external symbol __imp_fmax ...
... 50 unresolved externals total
alcove.exe : fatal error LNK1120: 50 unresolved externals

libort_sys's static archive leaves MSVC CRT externals unresolved.

macOS (aarch64-apple-darwin) is separately broken by a compiler-rt path regression on the Xcode 16.4 image (ld: library 'clang_rt.osx' not found) — workable around with a RUSTFLAGS=-L$(clang_rt dir) link-path injection, but a second sign that the static ort link is fragile across the matrix.

Impact

alcove rolled back to llm-kernel 0.9.2 (dynamic ort linking) to keep shipping releases — i.e. it cannot adopt 0.10–0.14 at all today. Any other downstream that builds release binaries on stock GitHub runners (ubuntu-22.04 / windows-latest) hits the same wall. cargo check / cargo test pass, so the failure only surfaces at release time.

Options to consider

1. Revert the default to dynamic linking, make static opt-in. The 0.12.0 changelog already ships embedding-fastembed-dynamic-linking as the documented escape hatch — flipping which one is default would keep embedding-fastembed on Linux force-enables ort-load-dynamic, causing a silent deadlock instead of a clear error when libonnxruntime.so isn't separately provided #50 fixed for the static-preferring minority without forcing every release-shipping consumer to discover this at tag time.
2. Ship a portability-conscious static archive — build the bundled ort static lib against an older glibc baseline (manylinux-style) and resolve the MSVC CRT link, so the static default actually works on stock runners.
3. At minimum, surface this in the feature table / README as a known limitation of embedding-fastembed (not just the CHANGELOG), and add a release-build (not just cargo check) CI matrix entry per feature so a static-link regression like this is caught upstream.

Environment

• llm-kernel 0.14.0 (regression introduced in 0.12.0)
• ort =2.0.0-rc.12, fastembed 5
• consumer: alcove 0.12.x (release run: https://github.com/epicsagas/alcove/actions/runs/28705148603)

Related: #50.