From: "René Scharfe" <l.s.r@web•de>
To: Johannes Schindelin <Johannes.Schindelin@gmx•de>,
Junio C Hamano <gitster@pobox•com>
Cc: git@vger•kernel.org
Subject: Re: [PATCH] regex: not all macOS platforms seem to have REG_ENHANCED
Date: Fri, 20 Mar 2026 12:12:00 +0100 [thread overview]
Message-ID: <5b8e24c2-452c-486e-a143-386e06a75e03@web.de> (raw)
In-Reply-To: <d340af9e-334c-4e81-e58a-fc3dea73ebdd@gmx.de>
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 <johannes.schindelin@gmx•de>
> 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 <johannes.schindelin@gmx•de>
> ---
> 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
next prev parent reply other threads:[~2026-03-20 11:12 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-19 22:37 [PATCH] regex: not all macOS platforms seem to have REG_ENHANCED Junio C Hamano
2026-03-19 23:11 ` René Scharfe
2026-03-20 1:30 ` Junio C Hamano
2026-03-20 7:34 ` Johannes Schindelin
2026-03-20 7:48 ` Johannes Schindelin
2026-03-20 7:55 ` Johannes Schindelin
2026-03-20 8:06 ` Johannes Schindelin
2026-03-20 8:55 ` Johannes Schindelin
2026-03-20 11:12 ` René Scharfe [this message]
2026-03-20 15:12 ` Johannes Schindelin
2026-03-20 15:59 ` René Scharfe
2026-03-20 16:33 ` Junio C Hamano
2026-03-20 16:57 ` Junio C Hamano
2026-03-20 16:50 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5b8e24c2-452c-486e-a143-386e06a75e03@web.de \
--to=l.s.r@web$(echo .)de \
--cc=Johannes.Schindelin@gmx$(echo .)de \
--cc=git@vger$(echo .)kernel.org \
--cc=gitster@pobox$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox