ship the libraries a compiled helper needs, and look for it where it lives (v0.5.5)
The DINOv2 GGUF embedder answered 500 for about twelve hours -- 6,176 image
embedding requests -- for two independent reasons, and the capability can be
dropped again by an ordinary rebuild, so both the lookup and the packaging are
fixed here.
The resolver looked only under /opt/coderai/bin, a directory that does not
exist in the image, and reported its absence as a generic load failure. It now
tries DINOV2_EMBED_BIN, then PATH, then the places the binary is actually
installed, and when it finds nothing it names every one of them plus the build
script -- because there is no fallback: llama.cpp cannot load a ViT-only arch,
so this binary is the only runtime this model has.
The binary was also never listed in the image build, having been compiled by
hand once; the next rebuild silently shipped without it. It is listed now,
along with the private shared libraries it cannot start without.
Those libraries are the larger half of the problem. The image has no system
OpenCV -- only the venv's cv2 wheel, a different version with mangled sonames
-- so the closure travels beside the binary in dinov2-embed-libs, reached
through its own RPATH rather than LD_LIBRARY_PATH: OpenCV placed in
local-libs would be offered to every process in the image, cv2 included, while
a private directory on one binary's RPATH cannot shadow anything.
Four things make that work, each learned by watching it fail:
- the whole dependency tail, not just libopencv_*. Debian's imgcodecs links
GDAL, GDCM and OpenEXR, which a JPEG decoder never calls and the loader
demands anyway. Copying three libraries left six still "not found".
- cp -L. Most of these paths are symlinks, and copying the link gives a
20-byte file -- which also made a first size estimate off by 7x.
- RPATH on every library, not only on the binary. patchelf writes
DT_RUNPATH, which unlike DT_RPATH is not inherited by a dependency's
dependencies, so the binary found imgcodecs and imgcodecs found nothing.
- everything above the base ABI, not only what the image lacks. libtiff.so.6
exists there, so it was skipped, and the newer GDAL then wanted
LIBTIFF_4.6.1 from it. Mixing distributions works only if the whole tier
comes from one of them.
What stays behind is what any Linux has: libc, libm, libstdc++, libgcc,
libgomp, pthread, dl, rt, the loader, and libvulkan, which must match the GPU
driver.
The tarball build had the same two gaps as the image build and is fixed with
it: it copied a binary without its -libs sibling, shipping a program that
cannot start, and a --local-binary-dir sweep would have flattened those .so
files into bin/ as programs, away from the only place the RPATH looks.
Verified against the HF vision backend on the same images: cosine 0.990-0.995
per image, with image-to-image geometry agreeing to 0.002-0.017 -- the
quantized binary and the reference implementation describe the same space, so
an index built by one stays valid under the other.
Co-Authored-By:
Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01S8LAP3ueNzQJtwzhgVbq66
Showing
Please
register
or
sign in
to comment