Re: configure picks a clang that doesn't match LLVM_CONFIG

On Tuesday, November 10th, 2026 at 2:36 AM, Henson Choi <assam258(at)gmail(dot)com> wrote:

> Hi Greg,

Hello Henson,

> I tested this on macOS. Environment:
>
> * macOS 27.2 / arm64
> * unpatched = master b7eee09eab7, patched = v2-0002 on top

Okay, very similar to my setup. I'm on macOS 27.2.1 with an Apple
M3 Pro with Xcode 27.2 (27B52).

> Here is what I could confirm, point by point.
>
> > configure finds clang only through PATH, independently of the LLVM
> > installation chosen with LLVM_CONFIG.
>
> Confirmed. On macOS this is the default state. My setup:
>
> * Xcode provides /usr/bin/clang (Apple clang 21.0.0,
> clang-2100.3.34.2), which is the only clang on PATH.

I have clang-2100.4.1.1

> * LLVM comes from Homebrew: llvm 21.1.7, llvm(at)19 19.1.7 and
> llvm(at)18 18.1.8. The
> llvm formulae are keg-only, so neither clang nor llvm-config is
> linked into /opt/homebrew/bin. Each version's clang lives only
> in its own llvm-config --bindir (e.g.
> /opt/homebrew/Cellar/llvm/21.1.7/bin).

Similar again, I too use Homebrew.
llvm 23.1.4
/opt/homebrew/Cellar/llvm/23.1.4/bin

> So without CLANG, unpatched configure picks /usr/bin/clang whether
> LLVM_CONFIG is llvm, llvm(at)19 or llvm(at)18(dot) Only LLVM_BINPATH points
> into Homebrew.
>
> I had never run into this myself. The configure wrapper script I
> use has always paired the two explicitly:
>
> --with-llvm LLVM_CONFIG=$(brew --prefix llvm)/bin/llvm-config
> CLANG="ccache $(brew --prefix llvm)/bin/clang"

I do similar, with meson "-Dllvm=enabled" and similar env vars.

> That is, an explicit CLANG, the usual way around this today. For
> these tests I ran configure without the wrapper and with CLANG
> removed from the environment.
>
> > * LLVM_CONFIG=llvm-config-19, clang on PATH is clang-21: configure
> > succeeds, and every JIT compilation then ends the backend:
> >
> > error: Unknown attribute kind (102) (Producer: 'LLVM21.1.8' Reader: 'LLVM 19.1.7')
>
> Same diagnostic here. With LLVM_CONFIG=llvm(at)19 (or llvm(at)18) the
> bitcode from Apple clang can't be read. Here it fails even before
> run time, in the bitcode index step of make install:
>
> LLVM ERROR: ThinLTO cannot create input file: Unknown attribute
> kind (102) (Producer: 'APPLE_1_2100.3.34.2_0' Reader: 'LLVM 19.1.7')
> make[2]: *** [install-postgres-bitcode] Error 134

Yep.

> > * LLVM_CONFIG=llvm-config-21, unversioned clang on PATH is clang-19:
> > configure succeeds, bitcode comes from clang-19, llvmjit.so links
> > LLVM 21. That combination happens to work.
>
> The direction doesn't save you on macOS, though. Even where the
> version numbers match, Apple clang 21 and Homebrew LLVM 21, it
> breaks. With LLVM_CONFIG=llvm (21), build and install succeed, but
> every JIT compilation ends the backend:
>
> FATAL: fatal llvm error: Unsupported stack probing method
>
> * It happens regardless of jit_inline_above_cost /
> jit_optimize_above_cost.
> * make check with JIT forced (jit_above_cost=0 etc.) fails 234 of
> 239 tests.
> * Forcing it via PG_TEST_INITDB_EXTRA_OPTS makes initdb fail.

Agree.

> > The meson build has always used the clang from llvm-config --bindir,
> > falling back to PATH. The attached patch makes configure do the same,
> > in the order Andres suggested in [1]: an explicit CLANG wins, then the
> > clang in llvm-config --bindir, then PATH.
>
> Confirmed. With the patch:

That's good to know, thanks!

> * llvm, llvm(at)19 and llvm(at)18 all pick the clang in --bindir.
> Install succeeds and JIT works ("Inlining true, Optimization
> true").
> * make check with JIT forced passes all 239 tests on LLVM 21.
> * With no clang in --bindir, the search falls through to PATH.
> With none anywhere, it ends with the same "clang not found" as
> before.
> * LLVM_BINPATH is still the --bindir value in every case after the
> later assignment was removed.
> * configure regenerated with autoconf 2.69 is byte-identical to the
> one in the patch.
> * make -C doc/src/sgml check passes.
>
> > Tested on Debian 13 with all three cases above, plus an explicit
> > CLANG="ccache clang-19", which is kept as given.
>
> Same here. CLANG given as a configure argument, in the environment,
> or as "ccache /opt/homebrew/opt/llvm/bin/clang" is used as given,
> both before and after the patch.

Good, thanks.

> > Since this changes which compiler configure picks, I haven't marked it
> > for backpatching
>
> Understood. Just for the record, this matters even more on macOS.
> There it is common to keep the clang that Xcode provides and install
> LLVM separately from Homebrew or MacPorts, so the combination above
> is a usual one. In that case a --with-llvm build comes out broken
> as above unless CLANG is set explicitly. That might be worth
> weighing when deciding on a backpatch.

Yes, thanks. I'm not against backpatching, just avoided the work in this
latest update.

> Based on the above, +1 for this change.

Fantastic, thanks for the in-depth review. For the record here's how I
setup/build/test on macOS using meson. I sentimentally prefer autoconf
given the number of years I've burned working with it, but meson is a
good deal faster and confusing in all sorts of new ways.

LLVM_CONFIG=$(brew --prefix llvm)/bin/llvm-config CLANG="ccache $(brew --prefix llvm)/bin/clang" meson setup --reconfigure -Dllvm=enabled -Dlz4=enabled -Dzstd=enabled -Duuid=e2fs -Dlibxslt=enabled -Dcassert=true -Dtap_tests=enabled -Ddocs_pdf=enabled -Ddocs_html_style=website -Dssl=openssl --pkg-config-path=/opt/homebrew/lib/pkgconfig -Dc_args="-I/opt/homebrew/include" -Dcpp_args="-I/opt/homebrew/include" -Dc_link_args="-L/opt/homebrew/lib" -Dcpp_link_args="-L/opt/homebrew/lib" -Dldap=disabled --werror --prefix=$(PWD)/install --buildtype=debug $(PWD)/build .

ninja all contrib install -C build

meson test -C build --no-rebuild -q --print-errorlogs --timeout-multiplier=0.1

sometimes I specify the portion of the tests like: --suite setup

just passing that along for clarity.

> Best regards,
> Henson

Now we just need a committer to review and/or commit. Were I to be
making the decision I do think that we should backpatch because this
represents a bug trying to use a supported feature on a supported
platform where Homebrew is very commonly used for things like LLVM.
It'd be nice to allow those on macOS to use LLVM should they want it.

regards,

-greg