dbctx v0.1.1's semantic search (onnxruntime_go/CGO) breaks Docker builds

[lovestaco]

Summary

Upgrading github.com/shrsv/dbctx to v0.1.1 (internal/mcpagent/schema_index.go) pulled in semantic (embedding-based) schema matching, which is on by default and requires github.com/yalue/onnxruntime_go — real CGO bindings (import "C", #cgo CFLAGS), not pure Go.

This breaks every Docker-based build path, which currently hardcodes CGO_ENABLED=0:

• Dockerfile.crosscompile (the one actually used by make docker-build, docker-build-push, docker-multiarch* via scripts/lrops.py) — 3 occurrences of CGO_ENABLED=0.
• Dockerfile (not currently referenced by any Makefile/lrops.py target as far as I can tell — may be legacy/unused, but has the same issue if it's ever used).

With CGO_ENABLED=0, the build fails outright:

github.com/yalue/onnxruntime_go: build constraints exclude all Go files

This was also confirmed breaking local dev (make run/make develop via Air) — .air.toml hardcoded CGO_ENABLED=0 in its build command too. That one's been fixed (flipped to CGO_ENABLED=1) since Air's builder runs natively on the dev machine with a working C toolchain. make raw-deploy (the actual production path, building directly on the dev/build machine, not in Docker) is unaffected the same way.

Why this isn't a simple flag flip for Docker

Dockerfile.crosscompile has two compounding problems beyond just enabling CGO:

1. Runtime base image is alpine:3.18 (musl libc). dbctx downloads a prebuilt libonnxruntime.so to ~/.dbctx at runtime and dlopens it — this is almost certainly a glibc-linked build (standard for official ONNX Runtime releases). It would very likely fail to load inside musl/Alpine even if the Go binary itself compiled fine. Fixing this means switching the runtime stage to a glibc-based image (e.g. Debian/Ubuntu-slim), which has knock-on effects (package names, non-root user creation syntax, image size).

2. True cross-compilation. This Dockerfile cross-compiles for arm64/arm/v7 from an amd64 buildx host via GOOS=/GOARCH=. CGO cross-compilation needs a per-target-arch C cross-compiler toolchain (e.g. aarch64-linux-musl-cross), which isn't installed by the current apk add curl git ca-certificates build deps.

Neither of these can be verified without an actual multi-arch docker buildx environment, which wasn't available when this was investigated.

Current status

• Docker/self-hosted image builds (make docker-build, docker-build-push, docker-multiarch, docker-multiarch-push, and their -dry/-interactive variants) are not currently used for this project's actual deployment (which goes through make raw-deploy directly on the host, not Docker), so this isn't blocking anything today. But it will block anyone relying on the Docker path until fixed.

Ask

• Verify whether CGO_ENABLED=1 + a glibc runtime base (Debian/Ubuntu-slim instead of Alpine) + proper cross-compiler toolchains actually produces a working multi-arch image with working semantic search at runtime.
• Alternatively, consider whether Docker/self-hosted builds should just run with dbctx's semantic search disabled (Options.NoSemantic: true at the call site in internal/mcpagent/schema_index.go, conditional on a build tag or env var) rather than carrying the CGO/native-runtime dependency into that distribution channel at all.

References

• internal/mcpagent/schema_index.go — dbctx.BuildAsync(ctx, dsn, nil), currently uses default Options (semantic on)
• go.mod — github.com/shrsv/dbctx v0.1.1, github.com/yalue/onnxruntime_go v1.32.1
• Dockerfile.crosscompile lines 57, 76, 80 — CGO_ENABLED=0
• Dockerfile line 80 — CGO_ENABLED=0 (possibly unused/legacy)
• .air.toml — already fixed (CGO_ENABLED=1) for local dev