From 705f40e7ad052657d67e63ee97bc46ee645a37ad Mon Sep 17 00:00:00 2001 From: Johannes Schindelin Date: Fri, 20 Mar 2026 09:09:10 +0100 Subject: [PATCH] osx-clang: work around Homebrew's clang lacking REG_ENHANCED The `osx-clang` and `osx-reftable` CI jobs on macOS started failing with: compat/regcomp_enhanced.c:7:13: error: use of undeclared identifier 'REG_ENHANCED' The failure coincides with the GitHub Actions `macos-14-arm64` runner image being updated from `20260302.0147` to `20260317.0174`. The key change in that image update is the Homebrew version bump from 5.0.15 to 5.1.0. Homebrew 5.1.0 introduced automatic linking for versioned keg-only formulae when the unversioned sibling is absent (see https://github.com/Homebrew/brew/pull/21676, announced at https://brew.sh/2026/03/10/homebrew-5.1.0/). The runner image installs `llvm@15` (keg-only) but not unversioned `llvm`. Under Homebrew 5.0.x that formula stayed in its keg and its `clang` binary only lived at `$(brew --prefix llvm@15)/bin/clang`. Under 5.1.0, because unversioned `llvm` is absent, `llvm@15` is now auto-linked into `/opt/homebrew/bin/`, which sits earlier in PATH than `/usr/bin`. The net effect is that `CC=clang` in CI now silently resolves to Homebrew's LLVM 15.0.7 clang instead of Apple's system clang (Apple clang 15.0.0, bundled with Xcode 15.4). The runner image README confirms this: the reported "Clang/LLVM" version flipped from 15.0.0 to 15.0.7 between image releases, matching the Homebrew LLVM version exactly. Homebrew's LLVM clang uses different include paths from Apple's clang. In particular, the `regex.h` it sees does not define `REG_ENHANCED`, which is an Apple-specific extension present in the macOS SDK headers since at least macOS 10.12. The Makefile unconditionally sets `USE_ENHANCED_BASIC_REGULAR_EXPRESSIONS` for all Darwin builds via `config.mak.uname`, which pulls in `compat/regcomp_enhanced.c`, which references `REG_ENHANCED`, hence the build failure. The `osx-gcc` job (CC=gcc-13) is unaffected because Homebrew GCC is configured to use Apple's SDK sysroot, so it still picks up Apple's `regex.h` which defines `REG_ENHANCED`. The `osx-meson` job is unaffected because Meson does a compile-time test for `REG_ENHANCED` (via `compiler.get_define`) and simply skips the feature when it is absent. Work around this by setting `NO_REGEX` when `CC=clang` on Darwin, which makes the build use Git's bundled regex implementation instead of the system one. This sidesteps the missing `REG_ENHANCED` define entirely. Signed-off-by: Johannes Schindelin --- config.mak.uname | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/config.mak.uname b/config.mak.uname index 6db9fd48d4f5c0..8a6fe5e8547a8f 100644 --- a/config.mak.uname +++ b/config.mak.uname @@ -160,6 +160,17 @@ ifeq ($(uname_S),Darwin) NEEDS_GOOD_LIBICONV = UnfortunatelyYes endif + # Homebrew's LLVM clang ships a regex.h that lacks REG_ENHANCED, + # which is needed for USE_ENHANCED_BASIC_REGULAR_EXPRESSIONS above. + # Use our bundled regex instead. This became a practical problem + # when Homebrew 5.1.0 started auto-linking versioned keg-only + # formulae (like llvm@15) into $(HOMEBREW_PREFIX)/bin/, causing + # CC=clang in CI to silently pick up Homebrew's clang instead of + # Apple's /usr/bin/clang. + ifeq ($(CC),clang) + NO_REGEX = HomebrewsClangUsesARegexThatLacksREG_ENHANCED + endif + # The builtin FSMonitor on MacOS builds upon Simple-IPC. Both require # Unix domain sockets and PThreads. ifndef NO_PTHREADS