From: Johannes Schindelin <Johannes.Schindelin@gmx•de>
To: "René Scharfe" <l.s.r@web•de>
Cc: Junio C Hamano <gitster@pobox•com>, git@vger•kernel.org
Subject: Re: [PATCH] regex: not all macOS platforms seem to have REG_ENHANCED
Date: Fri, 20 Mar 2026 16:12:20 +0100 (CET) [thread overview]
Message-ID: <58f3c772-6d38-0807-29c5-75e26c229c1d@gmx.de> (raw)
In-Reply-To: <5b8e24c2-452c-486e-a143-386e06a75e03@web.de>
[-- Attachment #1: Type: text/plain, Size: 3711 bytes --]
Hi René,
On Fri, 20 Mar 2026, René Scharfe wrote:
> On 3/20/26 9:55 AM, Johannes Schindelin wrote:
>
> > 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.
That makes sense! I couldn't investigate this because I do not have a
local macOS setup to test with, and I did not want to abuse GitHub
Actions' runners (nor did I want to spend more of my own time on the
investigation).
> 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.
Hmm. I am convinced, though, that if it hits CI, it hits human users as
well. Maybe the difference is that you upgraded from an existing setup
while the runners (I think) are built from scratch every time.
> > 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.
That would fix our CI runs, but it would expose users who set their `CC =
clang` to the same problem that broke our CI builds...
Ciao,
Johannes
>
> > 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 15: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
2026-03-20 15:12 ` Johannes Schindelin [this message]
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=58f3c772-6d38-0807-29c5-75e26c229c1d@gmx.de \
--to=johannes.schindelin@gmx$(echo .)de \
--cc=git@vger$(echo .)kernel.org \
--cc=gitster@pobox$(echo .)com \
--cc=l.s.r@web$(echo .)de \
/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