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

Hi Greg,

I tested this on macOS. Environment:

* macOS 27.2 / arm64
* unpatched = master b7eee09eab7, patched = v2-0002 on top

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

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"

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

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

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

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

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

Based on the above, +1 for this change.

Best regards,
Henson