ci-just-in-case build blocked: llama.cpp b8250 cpp-httplib link (owner decision needed)

[mrhegemon]

The Publish container workflow on main fails at the final link. After fixing 6 real build bugs (below), the build compiles everything and dies only on llama.cpp's own HTTP downloader.

Root cause (llama.cpp, not JIC code)

libcommon.a ships common/download.cpp, which calls cpp-httplib (httplib::Client/httplib::Response) for model downloads. In tag b8250 this is unconditional — LLAMA_CURL=ON does not remove it. The bundled cpp-httplib doesn't link in JIC's fully-static build and additionally wants OpenSSL (Could NOT find OpenSSL), so the final link fails with undefined reference to httplib::Client::....

Already fixed (on main via #7 and #9)

1. cpp-httplib download URL 404 → raw tagged single-header
2. missing unzip in the build stage
3. sqlite-vec amalgamation extracted nothing (--strip-components=1 on a flat tarball)
4. SQLITE_CORE defined globally (sqlite3ext.h) — sqlite link clean
5. OpenMP undefined refs → link libgomp
6. --recurse-submodules on the llama.cpp clone

Recommended fix (needs a maintainer call)

JIC bundles GGUF models locally and never uses llama's downloader, so the cleanest path is one of:

• Pin an llama.cpp tag that predates the in-tree cpp-httplib downloader (older tags use libcurl / have no in-tree HTTP). Lowest-risk, but verify the llama API JIC's server.cpp uses is unchanged.
• Or compile cpp-httplib as a real implementation TU with CPPHTTPLIB_OPENSSL_SUPPORT and link OpenSSL.

Either removes the link error. Once a target llama tag is chosen I can finish the Docker/CMake wiring. Everything else (amd64 image, screenshot gate, GHCR publish) is in place and works.

Note: ci-just-in-case is intentionally amd64-only (cross-compiling llama.cpp under QEMU-arm64 is impractical; the fleet is x86_64).

[mrhegemon]

Validated the recommended fix (option 1: pin a pre-httplib tag) with a native arm64 build — PR #11.

Findings

The right tag is b6591. Timeline established from upstream history:

• The cpp-httplib downloader entered common/ at b6593 (common : use cpp-httplib as a cURL alternative for downloads ggml-org/llama.cpp#16185, 2025-09-26) — initially as a cURL alternative.
• libcurl support was removed entirely in refactor : remove libcurl, use OpenSSL when available ggml-org/llama.cpp#18828 (2026-01-14), which is why LLAMA_CURL=ON does nothing at b8250 (the option no longer exists).
• b6591 (2025-09-26, commit 9b265118) is the newest published tag before the httplib downloader (b6592 was never published). Its common/ has no download.cpp/http.h; the curl downloader in arg.cpp is fully guarded by LLAMA_USE_CURL.

One flag had to change with the pin: -DLLAMA_CURL=OFF. With ON, libcommon.a at b6591 carries curl_easy_* references, and JIC's link line (--whole-archive libcommon.a, no -lcurl) fails the same way it did with httplib — just a different library. OFF compiles the downloader out entirely; JIC bundles its models so nothing is lost.

No API drift. All 37 llama_* symbols used by src/ exist in b6591's include/llama.h (verified against the tag before building). Build succeeded on the first attempt.

Second blocker found behind the link error: the screenshot gate in docker-publish.yml runs the container with an empty gguf_models/, and main() exited 1 when the embedding model failed to load — so the workflow still couldn't go green after the link fix. PR #11 makes the server start in degraded mode (UI + /status + /sources up, /query → 503 JSON, /status reports llm_loaded/embeddings_loaded).

Verification (arm64 native; production image stays amd64)

• Full docker build passes end-to-end (tag attempt 1 of a budgeted 3 — no retries needed)
• Container without models: Up (healthy), GET / 200, POST /query 503 with a clear JSON error, bundled source PDFs served
• tests/container Playwright gate: 1 passed
• Headless-Chromium console probe: no uncaught page errors

Remaining proof is the amd64 CI run on PR #11.