fatal llvm error: Unsupported stack probing method on llvm 18.1.7

[theory]

I found #57171, but I think that's included in recent releases, yes? I'm using llvm 18.1.7 (installed via Homebrew) and seeing this runtime error crashing Postgres during make check.

I'm building from postgres/postgres@81d20fb but also saw it in postgres/postgres@REL_16_STABLE (the Postgres 16 stable branch), so I don't believe it's an issue in Postres.

Build on a MacBook Pro with M1 CPU using Homebrew-installed libraries for readline, openssl, libxml2, ICU, and LLVM. The build script:

export PKG_CONFIG_PATH="/opt/homebrew/opt/icu4c/lib/pkgconfig"
export XML_CATALOG_FILES=/opt/homebrew/etc/xml/catalog

./configure \
    --prefix=$HOME/pgsql-devel \
    --with-perl \
    "PERL=$HOME/.plenv/shims/perl" \
    --with-libxml \
#    --with-llvm \
#    LLVM_CONFIG=/opt/homebrew/opt/llvm/bin/llvm-config \
    --with-uuid=e2fs \
    --with-zlib \
    --with-openssl \
    --enable-tap-tests \
    PKG_CONFIG_PATH=/opt/homebrew/opt/icu4c/lib/pkgconfig \
    'CPPFLAGS=-I/opt/homebrew/opt/readline/include -I/opt/homebrew/opt/openssl/include -I/opt/homebrew/opt/libxml2/include -I/opt/homebrew/opt/icu4c/include' \
    'CFLAGS=-I/opt/homebrew/opt/readline/include -I/opt/homebrew/opt/openssl/include -I/opt/homebrew/opt/libxml2/include -I/opt/homebrew/opt/icu4c/include' \
    'LDFLAGS=-L/opt/homebrew/opt/readline/lib -L/opt/homebrew/opt/openssl/lib -L/opt/homebrew/opt/libxml2/lib -L/opt/homebrew/opt/icu4c/lib'

make -j8
make install
make check

All tests pass with this configuration. However, if I uncomment the LLVM lines, make check fails:

+FATAL:  fatal llvm error: Unsupported stack probing method
+server closed the connection unexpectedly
+   This probably means the server terminated abnormally
+   before or while processing the request.
+connection to server was lost

The only oddity I noticed during compilation was this warning (repeated many times):

ld: warning: reexported library with install name '/opt/homebrew/opt/llvm/lib/libunwind.1.dylib' found at '/opt/homebrew/Cellar/llvm/18.1.6/lib/libunwind.1.0.dylib' couldn't be matched with any parent library and will be linked directly

Not sure if that's related. I also upgraded from llvm 18.1.6 to 18.1.7 and tried again, with the same results. See the successful build, the failed build, the upgrade of llvm, and another failed build in this gist:

https://gist.github.com/theory/347540b8c9bec569971c9f5661df69c3

I don't know where to find a crash log, alas. Its log output is:

2024-06-17 11:31:56.962 EDT client backend[14972] pg_regress/boolean FATAL:  fatal llvm error: Unsupported stack probing method
2024-06-17 11:31:56.962 EDT client backend[14972] pg_regress/boolean STATEMENT:  SELECT BOOLTBL1.*, BOOLTBL2.*
       FROM BOOLTBL1, BOOLTBL2
       WHERE BOOLTBL2.f1 <> BOOLTBL1.f1;
2024-06-17 11:31:56.962 EDT client backend[14972] pg_regress/boolean DEBUG:  shmem_exit(1): 4 before_shmem_exit callbacks to make

Other details:

• Homebrew 4.3.6-2-g088afff
• llvm 18.1.7
• readline 8.2.10
• openssl 3.3.1
• libxml2 2.12.8
• icu4c 74.2
• Apple clang version 15.0.0 (clang-1500.3.9.4)

[efriedma-quic]

The error message is LLVM reporting the backend can't handle the particular form of "probe-stack" attribute in the input LLVM IR. So this is likely a bug in the way postgres is generating LLVM IR: please file a bug against Postgres. (Feel free to reopen if you have some reason to believe the issue is on the LLVM side.)

[theory]

Thanks. I took that back to them, and @anarazel figured it out right away. Turns out I was using Homebrew LLVM but macOS Clang in /usr/bin. Passing CLANG=/opt/homebrew/opt/llvm/bin/clang to configure fixed the issue.

Kinda wish now the LLVM shipped with the Mac developer tools.

[anarazel]

I don't remember the exact history, but the reason we historically allowed these to diverge is that it historically wasn't easy to get clang matching LLVM versions. There were platforms where the available clang used a different version of LLVM than the available libllvm to link against. Also, historically, the breakages on the bitcode level seemed far less frequent these days, so using a different clang than the llvm version used to cause a lot fewer issues...