LocalLLMClientLlama: 'memory' file not found — C wrapper needs C++ stdlib

[gsdali]

Summary

LocalLLMClientLlama fails to build because its C wrapper target
(LocalLLMClientLlamaC) doesn't have C++ stdlib available — #include <memory> fails with "file not found". The wrapper is a C/Objective-C target
that includes C++ headers from llama.cpp (utils.h, chat.h) but isn't
configured to compile with the C++ stdlib.

Repro

Consume LocalLLMClient main + LocalLLMClientLlama from a Swift 6 package:

.package(url: "https://github.com/tattn/LocalLLMClient.git", revision: "<main HEAD>"),

.target(
    name: "MyTarget",
    dependencies: [
        .product(name: "LocalLLMClient", package: "LocalLLMClient"),
        .product(name: "LocalLLMClientLlama", package: "LocalLLMClient"),
    ],
    swiftSettings: [
        .interoperabilityMode(.Cxx),  // tried — doesn't help, since the
                                      // failure is in upstream's C target
    ]
),

swift build →

.build/checkouts/LocalLLMClient/Sources/LocalLLMClientLlamaC/include/utils.h:1:10:
error: 'memory' file not found
 1 | #include <memory>
   |          `- error: 'memory' file not found
 2 | #include "../common/chat.h"

<unknown>:0: error: could not build Objective-C module 'LocalLLMClientLlamaC'

The chain: LocalLLMClientLlamaC.h → mtmd.h → utils.h → <memory> →
not found because the target is built as Objective-C / C, not C++.

Likely fix

The LocalLLMClientLlamaC target in Package.swift needs cxxSettings (or
needs to be declared as a .target with publicHeadersPath configured for
C++ + a .headerSearchPath that picks up llama.cpp's common/ directory).
Something like:

.target(
    name: "LocalLLMClientLlamaC",
    dependencies: [/* llama-binary, etc. */],
    publicHeadersPath: "include",
    cSettings: [
        .headerSearchPath("../common"),
    ],
    cxxSettings: [
        .headerSearchPath("../common"),
        .define("..."),
    ],
    linkerSettings: [/* ... */]
)

Plus making the target file-extensions C++ if any of its own .m / .c files
are actually C++ in disguise.

The clean separation would be: a pure-C LocalLLMClientLlamaC target that
forwards to a separate C++ LocalLLMClientLlamaCxx target. But a cxxSettings
on the existing target is the minimum-disruption fix.

Context

Filed while wiring LocalLLMClient into OCCTSwiftPartsAgent. Pairs with
the MLX-backend Tokenizers issue (filed separately) — together they leave
LocalLLMClient unable to deliver any local-inference backend on current main.

For OCCTSwiftPartsAgent we've deferred the LocalLLMClient integration
pending a fix on either backend; the project meanwhile drives local
inference through OpenAI-compat (LM Studio) for Mac dev. The local
in-process path is needed for the iPad target, which can't run LM Studio.

[gsdali]

After investigating, the root cause turned out to be different from "C++ stdlib not on the include path" — it's a packaging issue, not a build-flag issue. Updating with what I found in case it's useful for the fix.

Root cause

Sources/LocalLLMClientLlamaC/ contains 25 symlinks pointing into the exclude/llama.cpp/ git submodule:

$ find Sources/LocalLLMClientLlamaC -type l
Sources/LocalLLMClientLlamaC/mtmd-helper.cpp           → exclude/llama.cpp/tools/mtmd/mtmd-helper.cpp
Sources/LocalLLMClientLlamaC/mtmd.cpp                  → exclude/llama.cpp/tools/mtmd/mtmd.cpp
Sources/LocalLLMClientLlamaC/clip.cpp                  → exclude/llama.cpp/tools/mtmd/clip.cpp
Sources/LocalLLMClientLlamaC/minja                     → exclude/llama.cpp/vendor/minja          (directory)
Sources/LocalLLMClientLlamaC/nlohmann                  → exclude/llama.cpp/vendor/nlohmann       (directory)
Sources/LocalLLMClientLlamaC/common/chat.h             → ../exclude/llama.cpp/common/chat.h
Sources/LocalLLMClientLlamaC/common/chat.cpp           → ../exclude/llama.cpp/common/chat.cpp
…25 total…

When SPM consumes the package via from:, revision:, or branch:, it checks out the package's source tree from the chosen ref but does not recursively fetch git submodules. Result: all 25 symlinks dangle in the consumer's .build/checkouts/LocalLLMClient/, and the C target fails to compile.

The error chain a downstream sees:

warning: ignoring broken symlink .../Sources/LocalLLMClientLlamaC/mtmd-audio.cpp
warning: ignoring broken symlink .../Sources/LocalLLMClientLlamaC/clip-impl.h
…
.build/checkouts/LocalLLMClient/Sources/LocalLLMClientLlamaC/include/utils.h:3:10:
fatal error: '../common/chat.h' file not found

The <memory> failure I originally reported is the same root cause hit at a slightly later point in the include chain — <memory> is found, but a header that includes it (utils.h) chains through to ../common/chat.h (a dangling symlink), and Clang's error rolls up to the first missing include. Different symptom, same cause.

The repro is just gh repo clone tattn/LocalLLMClient && swift build (no --recurse-submodules). Cloning with --recurse-submodules makes everything build cleanly.

Why downstream consumers can't work around it

SPM doesn't expose any hook that lets the consuming Package.swift say "also init submodules of this dep." There's no --recurse-submodules for SPM dependency resolution. The downstream build is stuck.

(I tried adding .interoperabilityMode(.Cxx) and various cSettings / cxxSettings on the consuming target — none of those help, because the failure is "files don't exist on disk," not a Clang flag issue.)

Possible fixes (all are architectural — flagging the trade-offs rather than picking one)

1. Vendor the symlinked files

Replace every symlink with a copy of its target's content. Drop the exclude/llama.cpp/ submodule (or keep it for upstream tracking but stop linking into it). Pro: SPM-safe, self-contained, no consumer surprises. Con: repo size grows (probably a few MB based on the file count); upstream llama.cpp updates become a manual sync.

2. SPM Build Tool Plugin

Add a .plugin(.buildTool, ...) that runs at build time, copies files from exclude/llama.cpp/ into the LocalLLMClientLlamaC source layout, then lets SPM compile normally. Pro: keeps the submodule as the source of truth. Con: only works if the submodule is present — same root problem. Plugins don't have hook into SPM's git fetch step.

3. Switch LocalLLMClientLlamaC to a binary target

Pre-build the C wrapper as an .xcframework (similar to how LocalLLMClientLlamaFramework already does it). Ship it as a .binaryTarget with the rest of the package. Pro: cleanest consumer experience. Con: heavy infrastructure — release process now needs an Xcode build step + checksum + URL.

4. Document a workaround

Add a prepare.sh script that consumers can run after dependency resolution to populate the symlink targets. Pro: minimal repo change. Con: terrible DX; SPM-via-Xcode users can't run shell scripts in .build/checkouts/.

I started a fork to try option 1 (vendoring) but pulled back since the diff would be massive (hundreds of files, MB-scale) and the maintainer is much better positioned to decide which trade-off matches the project's release/upstream-tracking workflow.

For now, I'm marking the LocalLLMClientLlama backend as blocked downstream and proceeding with MLX (separate fix in #95).