fix(macos): pass SDK to linker explicitly (-isysroot) — fixes -lSystem not found#162
Merged
Merged
Conversation
…k_path macOS `mcpp build` could fail at link with 'library not found for -lSystem' (plus every libSystem symbol undefined) even though compile succeeded. Root cause: the macOS link command (flags.cppm f.ld) never passed the SDK — it relied on clang's IMPLICIT SDK detection (xcrun/SDKROOT -> ld64 -syslibroot) to resolve -lSystem. On GitHub's clean Xcode runners that always works, so the gap was latent (CI green); on a real machine where detection fails (misconfigured xcode-select, CLT-only, fresh bundled clang) ld64.lld can't find libSystem. Code identical 0.0.60->0.0.61, hence 'CI ok, fresh install not'. Fix: - flags.cppm: add `-isysroot <SDK>` to the macOS f.ld so the linker gets the SDK deterministically (compile side already had --sysroot). - macos.cppm: harden sdk_path() with fallbacks — SDKROOT env, `xcrun --sdk macosx`, `xcode-select -p` derived SDK, then well-known CLT/Xcode paths — so the SDK is found even when `xcrun --show-sdk-path` returns empty. - doc: .agents/docs/2026-06-24-macos-link-lsystem-sdk.md (analysis + fix). Build: clean self-host. ci-macos validates the macOS link path.
Sunrisepeak
added a commit
that referenced
this pull request
Jun 24, 2026
Maps each symptom reported in #43 to its root cause, fix/status and the PR/doc that handles it: - headline -lSystem link failure -> #162 (-isysroot + sdk_path hardening) - first-run stdin hang -> #163 - ninja 145s / sub-index 404 -> tracked in #164 todo (non-blocking) - VS Code xattr / config-hook fail -> xlings recipe side (non-mcpp) The cross-platform CDB e2e in this PR (76) doubles as the macOS link regression guard: mcpp build links, so a -lSystem regression turns it red. CI-verified that 76 actually runs+passes on linux/macos/windows. Closes #43
Sunrisepeak
added a commit
that referenced
this pull request
Jun 24, 2026
…#165) * test(e2e): assert compile_commands.json is generated on all platforms Add a dedicated e2e (no requires → runs Linux/macOS/Windows) that builds a minimal `mcpp new` project and verifies the Clang compilation database is emitted at the project root: file exists + non-empty, top-level JSON array, required keys (directory/file + command|arguments), an entry for src/main.cpp, and a deeper python json parse where available. CDB generation is unconditional in the ninja backend (write_compile_commands), so this guards the IDE/clangd contract directly. Existing CDB tests cover specifics (47 prebuilt-module-path abs, 59 std flag, gcc-only); this is the plain cross-platform existence+validity guarantee. Verified: 47 already passes on Windows/macOS CI, confirming the build path works there. * docs(issue43): consolidated macOS first-run triage + close-out record Maps each symptom reported in #43 to its root cause, fix/status and the PR/doc that handles it: - headline -lSystem link failure -> #162 (-isysroot + sdk_path hardening) - first-run stdin hang -> #163 - ninja 145s / sub-index 404 -> tracked in #164 todo (non-blocking) - VS Code xattr / config-hook fail -> xlings recipe side (non-mcpp) The cross-platform CDB e2e in this PR (76) doubles as the macOS link regression guard: mcpp build links, so a -lSystem regression turns it red. CI-verified that 76 actually runs+passes on linux/macos/windows. Closes #43
Closed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Symptom
macOS
mcpp buildfails at link (compile OK):ld64.lld: error: library not found for -lSystem+ every libSystem symbol undefined. Reported on a freshly-installed 0.0.61; "worked before, CI is green".Root cause
The macOS link command (
flags.cppmf.ld) never passed the SDK — no-isysroot/--sysroot. The compile side gets--sysroot=<SDK>, but the linker relied on clang's implicit SDK detection (xcrun/SDKROOT→ ld64-syslibroot). GitHub's clean Xcode runners always detect it → latent gap (CI green). On a real machine where detection fails (misconfiguredxcode-select, Command-Line-Tools-only, fresh bundled clang) → ld64.lld can't findlibSystem. The macOS link code is identical 0.0.60→0.0.61, which is exactly why "CI ok, fresh install not."Fix
flags.cppm— add-isysroot <SDK>to the macOSf.ld(SDK frommacos::sdk_path()), making the SDK explicit on the link line.macos.cppm::sdk_path()— harden with fallbacks:SDKROOTenv →xcrun --sdk macosx --show-sdk-path→xcode-select -pderived.../SDKs/MacOSX.sdk→ well-known CLT/Xcode SDK paths. Finds the SDK even whenxcrun --show-sdk-pathreturns empty..agents/docs/2026-06-24-macos-link-lsystem-sdk.md.Safe: on CI
sdk_path()returns the Xcode SDK = what clang would implicitly detect, so no behavior change;ci-macosvalidates the link path. Build: clean self-host.