From: René Scharfe Date: Fri, 20 Mar 2026 11:12:00 GMT Subject: Re: [PATCH] regex: not all macOS platforms seem to have REG_ENHANCED Message-ID: <5b8e24c2-452c-486e-a143-386e06a75e03@web.de> In-Reply-To: On 3/20/26 9:55 AM, Johannes Schindelin wrote: > Me again, sorry, > > On Fri, 20 Mar 2026, Johannes Schindelin wrote: > >> On Fri, 20 Mar 2026, Johannes Schindelin wrote: >> >>> On Fri, 20 Mar 2026, Junio C Hamano wrote: >>> >>>> The build seems to have started failing on macos-14 CI jobs at >>>> GitHub, however, as apparently not all the macOS platforms have this >>>> flag defined. >> >> [... I need to ...] recommend something like this in the `Darwin` clause >> in `config.mak.uname`: >> >> -- snipsnap -- >> diff --git a/config.mak.uname b/config.mak.uname >> index f9ffefa67a4f..572f8967bc36 100644 >> --- a/config.mak.uname >> +++ b/config.mak.uname >> @@ -172,6 +172,10 @@ ifeq ($(uname_S),Darwin) >> NEEDS_GOOD_LIBICONV = UnfortunatelyYes >> endif >> >> + ifeq ($(CC),clang) >> + NO_REGEX = HomebrewsClangSeemsToBeMissingEnhancedRegexSupportAsOfMarch2026 >> + endif >> + >> # The builtin FSMonitor on MacOS builds upon Simple-IPC. Both require >> # Unix domain sockets and PThreads. >> ifndef NO_PTHREADS > > Turns out that my analysis was not _quite_ complete yet. With Claude Opus' > assistance, I was able to find the exact turn of events that led to the CI > failure. Here is my proposal for an alternative to your patch, Junio (the > https://github.com/git-for-windows/git/actions/runs/23335584918 shows that > the build completed successfully this time; the tests are still running as > of time of writing, of course): > > -- snipsnap -- > From f65b3b657c36e9132624ea223c90047527edea59 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. Good find! > 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. I suspect it uses the same regex.h. The definition of REG_ENHANCED is gated by a __MAC_OS_X_VERSION_MIN_REQUIRED check, though, and that fails because __MAC_OS_X_VERSION_MIN_REQUIRED is defined as __ENVIRONMENT_OS_VERSION_MIN_REQUIRED__ and that one in turn is not defined by the Homebrew version of clang in the runner. I can't reproduce this locally, by the way. /opt/homebrew/Cellar/llvm/22.1.1/bin/clang is not linked to /opt/homebrew/bin on my machine and also provides a sensible definition of __MAC_OS_X_VERSION_MIN_REQUIRED. > 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. Or how about using /usr/bin/clang explicitly on macOS instead of any old clang from $PATH? That would avoid user-visible changes. > 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 e6efd0f30913..c437accbcc50 100644 > --- a/config.mak.uname > +++ b/config.mak.uname > @@ -162,6 +162,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