812b70d4b7
All checks were successful
dev release / build (push) Successful in 2m39s
hestia (the actual deployment target) runs Ubuntu 24.04 (glibc 2.39); the shared Arch CI image tracks a much newer glibc (currently 2.43). A binary linked normally there requires GLIBC_2.43 symbols and refuses to start on hestia at all (glibc symbol versioning is forward-only) — this is what crashed breadarrd in production after its first bakery-managed install. Fix: ci/build.sh now pulls a real glibc + gcc-libs (for libstdc++) package pair from the Arch Linux Archive, matching hestia's actual versions, and links against them via --sysroot instead of the container's native ones. cargo-zigbuild (targeting an older glibc via zig's cross-linker) was tried first and doesn't work here: zig has no version database for libstdc++ specifically, and onnxruntime -- statically linked in by the ort crate -- needs a real, complete one. A real archived glibc+gcc-libs pair sidesteps that entirely. reqwest's native-tls now vendors (statically builds) OpenSSL instead of dynamically linking the build host's, since the old sysroot has no libssl/libcrypto of its own — also means the shipped binary no longer depends on the target system's OpenSSL version at all. Verified end-to-end on hestia's actual self-hosted runner: real ci/build.sh, real bread-ci:breadarr image, real docker build/run — produced binary requires GLIBC up to 2.39 and GLIBCXX up to 3.4.30 only, and actually starts and runs on hestia.
14 lines
245 B
Text
14 lines
245 B
Text
/target
|
|
/.ci-old-glibc
|
|
config.toml
|
|
*.db
|
|
*.db-wal
|
|
*.db-shm
|
|
|
|
# Local hygiene notes (not for commit)
|
|
|
|
# Leftover source tarballs (never commit these)
|
|
**/src.tar.xz
|
|
|
|
# graphify knowledge-graph output (local tool cache, not for commit)
|
|
graphify-out/
|