Linux: video is refused with libtfvideo.so in the server's lib directory, where capabilities finds it #1107

What happens

On Linux, plain v1.1.1 (b10231b9) does not load libtfvideo.so from the server's ../lib, where its refusal and packaging/RUNTIME.md say to put it and where capabilities looks. With the server at DIR/bin-b10231b9/tensorfold-native, the library at DIR/lib/libtfvideo.so beside the v1.1.1 release's libtfgrammar.so, and LD_LIBRARY_PATH not naming DIR/lib:

• capabilities --json reports the library found: {"name":"TensorFold video","feature":"video inputs (--vision)","soname":"libtfvideo.so","found":true,…}
• All 18 video requests sent were refused: 12 to /tokenize with HTTP 400 and 6 to /v1/chat/completions with HTTP 500. The answers that were printed carry this message, which rank 0's log also prints once as a warning:
  libtfvideo.so is required for video inputs (--vision); build the optional zig build video -Dffmpeg=PREFIX runtime against FFmpeg 9.0.2 and place it in lib beside the server; see packaging/RUNTIME.md

#1050's 80517fc3, whose tfvideo.zig and optional_libraries.zig are v1.1.1's, was refused the same way. With LD_LIBRARY_PATH naming DIR/lib, it served the videos and passed tools/zig/video_served.py's checks (run from a copy that reads the processor's prompt ids from a file computed with transformers 5.19.0 and PyAV 19.0.1; 12 of 12 clips equal).

Why

• zig/src/core/tfvideo.zig:30-36: the comment says "Beside the server (zig-out/native/lib, where zig build video installs it), then the loader's own search path". On macOS the list starts with @executable_path/../lib/libtfvideo.dylib; on Linux it holds libtfvideo.so alone, which dlopen looks up on the loader's path only. readelf -d shows no RPATH or RUNPATH in the binaries; NEEDED is libc.so.6 for a source build, and libc.so.6, libpthread.so.0 and libdl.so.2 for the release archive's bin/tensorfold-native.
• zig/src/platform/optional_libraries.zig:99-105: for the entries marked local, video among them (:32), capabilities tries the server's ../lib and the server's own directory first, so it finds the file the video loader does not open.
• The other local libraries' loaders look in the same places, the server's ../lib, its own directory, then the loader's path: core/lanes/grammar.zig:27-39, core/picture/jpeg.zig:63-79 and core/picture/webp.zig:44-60.
• The refusal (optional_libraries.zig:32) and packaging/RUNTIME.md:42 ("installed in the server's lib directory") send the library there. RUNTIME.md:60 says, for runtimes in general, to add the directory to LD_LIBRARY_PATH "when an installed runtime is outside the loader's normal search path".

Either the Linux list could try the server's ../lib first, as the macOS list and the other local loaders do, or the refusal and RUNTIME.md's video row could say that on Linux the directory goes on LD_LIBRARY_PATH; with the second, capabilities would still report the file in ../lib found.

To reproduce

On Linux (a GB10, aarch64), with v1.1.1 built from source and libtfvideo.so from zig build video -Dffmpeg=PREFIX over a static FFmpeg 9.0.2, laid out as DIR/bin-b10231b9/tensorfold-native and DIR/lib/libtfvideo.so:

DIR/bin-b10231b9/tensorfold-native capabilities --json   # "TensorFold video" ... "found":true
DIR/bin-b10231b9/tensorfold-native serve ... --vision    # every video request refused as above

The serves were GLM-5.3-Flash NVFP4 at TP=2 on two GB10s. Their logs are in #1050's receipt: tp2/serve/vd-111 (plain v1.1.1), vd-nv and vl-nv (80517fc3 without and with LD_LIBRARY_PATH).

Not run: plain v1.1.1 with LD_LIBRARY_PATH (only #1050's 80517fc3 was served that way), the release archive's own binary with a video, macOS and Windows.

Written with Weave (My Symbiotic AI)