Skip to content

Fix macOS CI build: only build static re2 library#8347

Closed
bouwkast wants to merge 1 commit into
masterfrom
steven/fix-macos-re2-build
Closed

Fix macOS CI build: only build static re2 library#8347
bouwkast wants to merge 1 commit into
masterfrom
steven/fix-macos-re2-build

Conversation

@bouwkast

@bouwkast bouwkast commented Mar 19, 2026

Copy link
Copy Markdown
Collaborator

Summary

Our CI is broken on master as building on macos is failing due to a runner update.
Build only the static re2 library (obj/libre2.a) on macOS instead of the default all target which also builds the shared library (libre2.dylib).

Reason for change

CI is broken.

Implementation details

Some of the related issues associated with this suggested some workarounds, I just instructed Claude to fix, I didn't test it figure if the build works we are good.

Related issues

Test coverage

If the CI passes then we should hopefully be good?

Generated by Claude

The macOS runner image updated llvm@15 to an x86_64-only build,
breaking the arm64 cross-compile of libre2.dylib which links against
libunwind. We only need the static library (libre2.a), so target it
explicitly to avoid the shared library link step entirely.

See: actions/runner-images#13827
See: actions/runner-images#13816
@bouwkast bouwkast requested a review from a team as a code owner March 19, 2026 19:48
@bouwkast bouwkast added the AI Generated Largely based on code generated by an AI or LLM. This label is the same across all dd-trace-* repos label Mar 19, 2026

@link04 link04 left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🤞

@bouwkast

Copy link
Copy Markdown
Collaborator Author

😢
It still failed so will have to look into

@bouwkast bouwkast closed this Mar 19, 2026
andrewlock pushed a commit that referenced this pull request Mar 20, 2026
## Summary of changes

Attempt to fix macOS native build failure caused by the macos-14 runner
image updating llvm@15 to x86_64-only.

## Reason for change

CI is broken

The macos-14 runner image (20260316.0303) rebuilt Homebrew's llvm@15 as
x86_64-only. This breaks our arm64 cross-compilation because Homebrew's
libunwind.dylib shadows the system's universal version in the linker
search path. The linker finds the x86_64-only copy, ignores it for
arm64, and fails to resolve __Unwind_Resume.

## Implementation details

From Claude:

 The fix has two layers:

**1. Build only the static re2 library on macOS**
(`build/cmake/FindRe2.cmake`)

Changed `$(MAKE) -j` to `$(MAKE) -j obj/libre2.a` for both arm64 and
x86_64 re2 builds. The default make target builds both `libre2.a`
(static) and `libre2.dylib` (shared). The shared library link fails
because the linker picks up the x86_64-only libunwind. We only use the
static library (`IMPORTED_LOCATION` and `BUILD_BYPRODUCTS` both
reference `obj/libre2.a`), so the shared library was never needed.

**2. Isolate macOS builds from Homebrew via SDK sysroot**
(`Build.Steps.cs`, `Build.Shared.Steps.cs`)

- Resolve the macOS SDK path via `xcrun --show-sdk-path` and pass it as
`-DCMAKE_OSX_SYSROOT` to cmake. This causes cmake to pass
`-Wl,-syslibroot,<path>` to the linker, which prepends the sysroot to
all
default search directories. `/usr/local/lib` becomes
`<sysroot>/usr/local/lib` (doesn't exist in the SDK, so Homebrew's
libunwind is never found) while `/usr/lib` becomes `<sysroot>/usr/lib`
(contains TBD
  stubs for the real universal system libunwind).
- Clear `LDFLAGS` and `LIBRARY_PATH` environment variables to prevent
any additional Homebrew-injected paths from leaking into the build.

Applied to both `CompileNativeSrcMacOs` (tracer) and
`CompileNativeLoaderOsx` (native loader).


## Test coverage

Ran a build and it did work, now to see if this _actually_ works then
maybe we are good 🤷

## Other details
FWIW I don't really have a great understanding of the macOS build
Re-attempt of #8347

Generated with Claude
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

AI Generated Largely based on code generated by an AI or LLM. This label is the same across all dd-trace-* repos

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants