configure picks a clang that doesn't match LLVM_CONFIG
Hello again hackers,
I've been toying with LLVM-related code recently while I finished up
a new extension [1]https://codeberg.org/gregburd/pg_pure that also uses the LLVM. That led me to this
finding.
configure finds clang only through PATH, independently of the LLVM
installation chosen with LLVM_CONFIG. On Debian 13, which ships LLVM 19
by default with 21 in trixie-backports, this goes wrong in both
directions:
* 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.
* 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')
(That's LLVM's default diagnostic handler calling exit(1) while
reading llvmjit_types.bc, so it shows up as a backend exiting with
status 1 rather than a crash.)
* LLVM_CONFIG=llvm-config-21 and no unversioned clang on PATH:
configure fails, although /usr/lib/llvm-21/bin/clang is right there.
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]https://codeberg.org/gregburd/pg_pure: an explicit CLANG wins, then the
clang in llvm-config --bindir, then PATH. An explicit CLANG is still
the way to use a faster clang when building against an assertion-enabled
LLVM, which was Andres's concern about always using the bundled one.
Tested on Debian 13 with all three cases above, plus an explicit
CLANG="ccache clang-19", which is kept as given.
Since this changes which compiler configure picks, I haven't marked it
for backpatching; it applies to 17 through 19 if a committer thinks it
should go back.
This has come up before ([2]/messages/by-id/2eda6b0f-cf08-b847-c33a-cb0e746d21ef@iki.fi, Heikki in 2018, and in [3]/messages/by-id/C5C97974-FB47-45AF-9DD3-30969302866A@anarazel.de), and Jelte hit
the same mismatch more recently while testing typeof_unqual.
best.
-greg
[1]: https://codeberg.org/gregburd/pg_pure
[2]: /messages/by-id/2eda6b0f-cf08-b847-c33a-cb0e746d21ef@iki.fi
[3]: /messages/by-id/C5C97974-FB47-45AF-9DD3-30969302866A@anarazel.de