darwin/arm64 vibevoice-cpp backend image ships sources instead of build artifacts — backend cannot start

[enneo-service]

LocalAI version: 4.4.1 (Homebrew bottle)
Environment: macOS (Apple Silicon, M1 Max), darwin/arm64

What happened

The darwin/arm64 vibevoice-cpp backend image appears to ship the source tree instead of build artifacts, so the backend can never start.

Steps to reproduce

1. local-ai backends install vibevoice-cpp — resolves to metal-vibevoice-cpp, downloads and installs fine
2. local-ai models install vibevoice-cpp-asr — model + tokenizer download fine (9.7 GB)
3. curl http://127.0.0.1:1240/v1/audio/diarization -F file=@two_speakers.wav -F model=vibevoice-cpp-asr

Result, consistently after ~40 s:

{"error":{"code":500,"message":"failed to load model with internal loader: grpc service not ready","type":""}}

No backend process ever appears.

Root cause (from inspecting the installed backend dir)

~/.localai/backends/metal-vibevoice-cpp/ contains CMakeLists.txt, Makefile, main.go, govibevoicecpp.go, cpp/, sources/ — and build-libgovibevoicecpp-fallback.so is a directory (a half-built CMake tree: CMakeFiles/, CMakeCache.txt, no artifacts inside).

run.sh ends with:

exec $CURDIR/vibevoice-cpp "$@"

but there is no vibevoice-cpp binary anywhere in the package, and no libgovibevoicecpp-*.so / .dylib library either — so the exec fails instantly and LocalAI just times out waiting for the gRPC service.

It looks like the darwin packaging step published the build tree instead of the built backend. For comparison, metal-llama-cpp and metal-whisper from the same gallery install and run fine on the same machine.

Expected

The darwin/arm64 image contains the built vibevoice-cpp binary (+ its library), like the other metal backends.

[localai-bot]

Fixed by #10276 (merged).

You diagnosed the symptom exactly. The underlying root cause turned out to be a CMake linkage bug, which the darwin CI surfaced clearly:

No rule to make target 'vibevoice/libvibevoice.a', needed by 'libgovibevoicecpp.so'.  Stop.

The upstream vibevoice project is added with EXCLUDE_FROM_ALL, so its vibevoice static-library target is only built when something links it as a target. The Apple branch linked only $<TARGET_FILE:vibevoice> (a bare archive path, no target reference), so CMake never emitted a rule to build libvibevoice.a — the build failed at the link step and left the half-built build-libgovibevoicecpp-fallback.so/ tree you found, which then got packaged.

What changed:

• The real fix: on Apple, link the vibevoice target (establishing the build dependency) and apply -force_load as a separate link option to keep whole-archive semantics (so purego can dlsym the vv_capi_* symbols).
• Fail-safe packaging (applies to every Go darwin backend): the packaging step now removes stray CMake build directories and refuses to package a backend whose binary doesn't exist — so a broken build fails CI loudly instead of ever shipping a source tree as a "backend" again.

Verified: the vibevoice-cpp darwin/arm64 build now succeeds end-to-end on the macOS CI runner (configure → compile ggml/metal/blas → build libvibevoice.a → link → go build → package).

The fixed darwin/arm64 image will be available once backend images are published from master. Please re-test local-ai backends install vibevoice-cpp then — it should now ship the real binary + library. Thanks for the thorough teardown of the installed backend dir; it made the diagnosis fast.