llama-server.exe –version Reports Hardcoded Placeholder Version Instead of Actual llama.cpp Build Metadata

Summary

llama-server.exe --version outputs version: 0.2.0-dev (build 1, commit xxxxxx) — a hardcoded fallback — instead of the real upstream version and build number. The root cause is that the Lemonade SDK's bundled llama-server.exe binary was compiled without proper injection of git-derived build metadata, causing llama.cpp's template to retain its placeholder defaults. The practical impact is that operators cannot reliably determine which llama.cpp revision is running, which hampers debugging, compatibility checks, and regression tracking.

Root-Cause Analysis

Confirmed Evidence

• The reported version string is version: 0.2.0-dev (build 1, commit xxxxxx).
• The literal string xxxxxx is the default fallback commit placeholder defined in llama.cpp's common/build-info.cpp.in template. It appears verbatim when the CMake build system cannot resolve git metadata at compile time.
• build 1 is similarly the static default for BUILD_NUMBER in the same template.
• The expected upstream string (version: 0.3.0-dev (build 10621, commit c1d0e7a00)) is substantially different, indicating the Lemonade-distributed binary is either tracking a different upstream fork point or was vendored from a snapshot that predates proper version wiring.

How llama.cpp Embeds Version Information

llama.cpp populates version metadata through a two-stage CMake mechanism:

1. cmake/build-info.cmake executes git rev-parse, git log, and git describe at configure time to extract commit hash, build number, and version string.
2. The results are substituted into common/build-info.cpp.in, which is rendered to build-info.cpp before compilation.

When this mechanism fails — for example, when building from a source archive without a .git directory, when the git executable is absent from the build environment, or when CMake variables are not forwarded correctly — the template substitution is skipped and the literal placeholders (xxxxxx, 1, 0.x.0-dev) are compiled directly into the binary.

Reasonable Inferences

• The Lemonade SDK build pipeline likely packages llama-server.exe from a vendored source snapshot or a CI environment that does not have git history available, causing the fallback path to activate.
• The version mismatch (0.2.0-dev vs. 0.3.0-dev) suggests the bundled binary may be pinned to an older llama.cpp upstream commit than what is currently shipping from ggml-org, or the CMake version string variable itself was not updated in the fork.

Alternative Cause

If the Lemonade build pipeline does have git available, the CMake variable -DLLAMA_BUILD_NUMBER or -DLLAMA_BUILD_COMMIT may simply not be passed during the cmake --build invocation, or the build-info.cmake include is missing from the top-level CMakeLists.txt integration within the Lemonade fork.

What Cannot Be Confirmed Without Additional Evidence

• Whether the functional llama.cpp code inside the binary actually corresponds to 0.3.0-dev or an earlier revision — only the metadata is known to be wrong.
• Whether this is a deliberate pin or an accidental omission in the build pipeline.

Resolution Steps

For Lemonade SDK Maintainers (Authoritative Fix)

1. Ensure a full git clone is available in CI when building llama-server.exe. Shallow clones (--depth 1) are sufficient as long as git rev-parse HEAD resolves correctly.

1. Verify that cmake/build-info.cmake is included in the CMake configuration used to build the Lemonade distribution of llama.cpp. Check that the top-level CMakeLists.txt contains:

   include(cmake/build-info.cmake)

1. Pass explicit build metadata via CMake cache variables if the git environment is unavailable or unreliable:

   -DLLAMA_BUILD_NUMBER=<BUILD_NUMBER>
   -DLLAMA_BUILD_COMMIT=<GIT_COMMIT_HASH>
   -DLLAMA_BUILD_VERSION=<SEMVER_STRING>

1. Align the version string in CMakeLists.txt (the project(... VERSION ...) directive or equivalent version variable) with the upstream ggml-org tag being vendored, so that --version output reflects the correct semantic version.

1. Rebuild and repackage llama-server.exe with the corrected build configuration and publish an updated Lemonade release.

For End Users (Workaround — Cannot Permanently Fix the Binary)

The embedded version string is compiled into the binary and cannot be changed at runtime. However, you can attempt to correlate the actual llama.cpp revision by:

1. Checking the Lemonade release notes or CHANGELOG for the specific llama.cpp commit or tag that was vendored in v11.7.0.
2. Comparing behavioral feature flags or API responses from llama-server against known llama.cpp changelogs to infer the actual revision.

CLI Commands

Check the version string reported by the binary:

llama-server.exe --version

If you have access to the Lemonade source repository, inspect what upstream llama.cpp commit is pinned:

git -C <PATH_TO_LEMONADE_REPO> submodule status

If building from source, configure CMake with explicit version injection:

cmake -S . -B build \
  -DLLAMA_BUILD_NUMBER=$(git rev-list --count HEAD) \
  -DLLAMA_BUILD_COMMIT=$(git rev-parse --short HEAD) \
  -DCMAKE_BUILD_TYPE=Release

cmake --build build --config Release --target llama-server

Configuration Snippets

In cmake/build-info.cmake, the critical section that should produce real values looks like this. Verify it is not being skipped:

find_package(Git)
if(Git_FOUND)
  execute_process(
    COMMAND ${GIT_EXECUTABLE} rev-parse --short HEAD
    WORKING_DIRECTORY ${CMAKE_SOURCE_DIR}
    OUTPUT_VARIABLE BUILD_COMMIT
    OUTPUT_STRIP_TRAILING_WHITESPACE
    ERROR_QUIET
  )
  execute_process(
    COMMAND ${GIT_EXECUTABLE} rev-list --count HEAD
    WORKING_DIRECTORY ${CMAKE_SOURCE_DIR}
    OUTPUT_VARIABLE BUILD_NUMBER
    OUTPUT_STRIP_TRAILING_WHITESPACE
    ERROR_QUIET
  )
else()
  set(BUILD_COMMIT "unknown")
  set(BUILD_NUMBER 0)
endif()

If BUILD_COMMIT resolves to xxxxxx or unknown after this block runs, the git executable is unavailable or the working directory has no git history.

Verification

After applying the build fix and repackaging:

llama-server.exe --version

Expected healthy output (values will vary by actual commit):

version: 0.3.0-dev (build 10621, commit c1d0e7a00)

Confirm that:

• The commit hash is not xxxxxx or unknown.
• The build number is not 1 (unless the repository genuinely has only one commit).
• The version string matches the upstream ggml-org tag or commit range that Lemonade vendors.

Prevention

1. CI pipeline gate: Add a post-build check in CI that runs llama-server.exe --version and fails the pipeline if the output contains xxxxxx or build 1.

   llama-server.exe --version | grep -E 'commit (x{6}|unknown)' && echo "VERSION METADATA MISSING — FAILING BUILD" && exit 1

1. Explicit version injection in CI: Always pass -DLLAMA_BUILD_NUMBER and -DLLAMA_BUILD_COMMIT as CI environment-derived values rather than relying on git availability in the build container.

1. Submodule policy: When vendoring llama.cpp as a submodule or source snapshot, record the upstream tag or commit SHA explicitly in release notes and ensure the CMake version variable is updated to match.

1. Release artifact validation: Include --version output in the release artifact manifest or changelog so users can cross-reference the bundled llama.cpp revision without building from source.