GHA ci is failing on PG15-clang-geos311-gdal35 C compiler works... no

[robe]

​https://github.com/postgis/postgis/actions/runs/5242404014/jobs/9465763896

======================================
Now you are ready to run './configure'
======================================
checking for a BSD-compatible install... /usr/bin/install -c
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu
checking how to print strings... printf
checking for gcc... clang
checking whether the C compiler works... no
configure: error: in `/src/postgis':
configure: error: C compiler cannot create executables
See `config.log' for more details
Error: Process completed with exit code 77.

This started failing last week, so guessing it's most likely something wrong with the ci docker build than anything wrong with our code

[robe]

Okay looked at this closer, putting in an echo on clang —version

It looks like our scripts in github/run_usan_clang.sh are hard-coded to work with clang 11. I suspect this broken when debian-slim (I'm guessing it's based on bookworm but haven't looked) started shipping with clang 14.

I discovered this by having the script output clang —version.

​https://github.com/robe2/postgis/actions/runs/5295165329/jobs/9585211344

The PG13 clang that still works was built a while ago and shows:

 Debian clang version 11.0.1-2

While the new one pg15-clang-geos311-gdal35-proj90

shows:

Debian clang version 14.0.6
Target: x86_64-pc-linux-gnu

and errors out in the usan_clang script:

ERROR: ld.so: object '/usr/lib/clang/11/lib/linux/libclang_rt.asan-x86_64.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.

I'm going to confirm that by hardcoding 14 and if that works try to make it conditional based on clang version

[robe]

Confirmed the new one failing is bookworm

PRETTY_NAME="Debian GNU/Linux 12 (bookworm)" NAME="Debian GNU/Linux" VERSION_ID="12" VERSION="12 (bookworm)" VERSION_CODENAME=bookworm ID=debian 

The old one working is bullseye

PRETTY_NAME="Debian GNU/Linux 11 (bullseye)" NAME="Debian GNU/Linux" VERSION_ID="11" VERSION="11 (bullseye)" VERSION_CODENAME=bullseye ID=debian 

However it's not just the LD_LOAD at fault. There are some of these flags that the new clang doesn't like:

# Enable undefined behaviour sanitizer using traps
CFLAGS_USAN="-g3 -O0 -mtune=generic -fno-omit-frame-pointer -fsanitize=undefined,implicit-conversion -fsanitize-undefined-trap-on-error -fno-sanitize-recover=implicit-conversion"
LDFLAGS_STD="-Wl,-Bsymbolic-functions -Wl,-z,relro"

# Sanitizer options to continue avoid stopping the runs on leaks (expected on postgres binaries)
export ASAN_OPTIONS=halt_on_error=false,leak_check_at_exit=false,exitcode=0
export MSAN_OPTIONS=halt_on_error=false,leak_check_at_exit=false,exitcode=0

./configure CC=clang CFLAGS="${CFLAGS_USAN}" LDFLAGS="${LDFLAGS_STD}"

[Regina Obe <lr@…>]

In c055f1ac/git:

FIX GHA clang failures for clang 14

• remove explicit conversion, seems to cause clang 14 to fail
• base path of LD_PRELOAD based on major version of clang instead of hard-coded 11

Closes #5400

[Regina Obe <lr@…>]

In 9025c77/git:

FIX GHA clang failures for clang 14

• remove explicit conversion, seems to cause clang 14 to fail
• base path of LD_PRELOAD based on major version of clang instead of hard-coded 11

Closes #5400 for PostGIS 3.3.10