build from source fails on cachyos

[haarer]

Version

codebase-memory-mcp dev

Platform

Linux (x64)

Install channel

Built from source

Binary variant

standard

What happened, and what did you expect?

clone repo, run scripts/build.sh
got build errors
some related to -Werror=discarded-qualifiers
some related to a missing include needed for recent libgit

gcc (GCC) 16.1.1 20260430
pkg-config --modversion libgit2 1.9.4

I think it is, because gcc 16.1.1 is picky about discarded qualifiers by default.

these changes let it build

❯ git diff
diff --git a/internal/cbm/cbm.c b/internal/cbm/cbm.c
index d611f18..81bc99d 100644
--- a/internal/cbm/cbm.c
+++ b/internal/cbm/cbm.c
@@ -21,6 +21,7 @@
#include "sqlite3.h" // sqlite3_mem_methods, sqlite3_config, SQLITE_CONFIG_MALLOC — bind sqlite to mimalloc
#if defined(HAVE_LIBGIT2)
#include <git2.h> // git_allocator, git_libgit2_opts, GIT_OPT_SET_ALLOCATOR — bind libgit2 to mimalloc
+#include <git2/sys/alloc.h>
#endif
#endif
#include <stdint.h> // uint32_t, uint64_t, int64_t
diff --git a/src/cli/cli.c b/src/cli/cli.c
index 4228dba..8219da6 100644
--- a/src/cli/cli.c
+++ b/src/cli/cli.c
@@ -1457,12 +1457,12 @@ int cbm_remove_codex_mcp(const char config_path) {
/ Splice out an existing [CODEX_HOOK_BEGIN .. CODEX_HOOK_END] block (inclusive,

• plus a leading newline). Returns a newly-malloc'd string the caller frees, or
• NULL if no block was present (content is left untouched). */
  -static char *codex_hook_strip(const char *content) {

• char *begin = strstr(content, CODEX_HOOK_BEGIN);
  +static char *codex_hook_strip(const char *content) {

• const char *begin = strstr(content, CODEX_HOOK_BEGIN);
  if (!begin) {
  return NULL;
  }

• char *end = strstr(begin, CODEX_HOOK_END);

• const char *end = strstr(begin, CODEX_HOOK_END);

Reproduction

reproducible on vanilla cachyos, just clone the repo and try to build.

Logs

Project scale (if relevant)

No response

Confirmations

• I searched existing issues and this is not a duplicate.
• My reproduction uses shareable code (a dummy snippet or a public OSS repository), not proprietary code.

[DeusData]

Hey, yes we are currently in a "in between release" phase. It's currently not all verified to be working. Please use the release binaries from 0.8.1 or check out to the commit version listed in the release :)

[haarer]

Am 24. Juni 2026 00:23:08 MESZ schrieb Martin Vogel ***@***.***>:

Closed #589 as completed. -- Reply to this email directly or view it on GitHub: #589 (comment) You are receiving this because you authored the thread. Message ID: ***@***.***>

No worries martin ;) But actually i checked out v0.8.1, not head. So i dont think that's an in between issue. Best regards, Alexander -- Gruß, Alexander

[DeusData]

@haarer alright will have a look, thx for reporting

[DeusData]

Thanks for the persistence on this — and you were right to push back. v0.8.1 is a
release tag, not an in-between state. Apologies for the confusion.

Your diff looks directionally correct. Before we merge, we want to confirm the
<git2/sys/alloc.h> path is stable across distros and that no older toolchain breaks
with the const char * changes. Could you share:

Instructions for your coding agent:

# 1. Full build output with errors highlighted
cd /path/to/codebase-memory-mcp
bash scripts/build.sh 2>&1 | tee /tmp/cbm-build-589.log
grep -n 'error:\|warning:.*-Werror' /tmp/cbm-build-589.log | head -60

# 2. Compiler and libgit2 details
gcc --version
pkg-config --modversion libgit2
pkg-config --cflags libgit2

# 3. Where is git2/sys/alloc.h on your system?
find /usr -name 'alloc.h' -path '*/git2/*' 2>/dev/null
find /usr -name 'alloc.h' -path '*/git2/sys/*' 2>/dev/null

# 4. After applying your diff, does it build cleanly?
bash scripts/build.sh 2>&1 | grep -Ec '^.*(error|warning.*Werror):'
# Expected: 0

# 5. Smoke test the built binary
./codebase-memory-mcp --version

The find output (step 3) confirming git2/sys/alloc.h exists at that path is the
most important piece — it determines whether we can use the include unconditionally or
need a configure-time check.

Thanks for the patch and for the detailed context!

[github-actions]

Thanks for the report! To move this forward we need a bit more so we can reproduce it ourselves:

• the codebase-memory-mcp --version you're on
• the exact steps or command you ran
• a public repo (or a small dummy snippet) that shows the problem — please don't paste proprietary code

Once that's here we'll pick it straight back up. Heads-up: issues left awaiting-reporter are automatically closed after a few weeks of silence, but a comment reopens the door anytime.