Re: [PATCH] regex: not all macOS platforms seem to have REG_ENHANCED

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Mar 20, 2026, 15:12 UTC
Message-ID: <58f3c772-6d38-0807-29c5-75e26c229c1d@gmx.de>
In-Reply-To: <5b8e24c2-452c-486e-a143-386e06a75e03@web.de>

Hi René,

On Fri, 20 Mar 2026, René Scharfe wrote:

Show 15 quoted lines

> 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.

Show 13 quoted lines

> > 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

Show 31 quoted lines

> 
> > 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
> 
> 
>