My apologies regarding the gcc version. We have tested this on both bullseye ( and bookworm. I have tested on both bookworm (gcc 12.2.0) we also tested on bullseye (gcc 10.2.1) to verify it wasnt GCC related, I extracted the build version from the wrong logs.
I had some communication with our build system provider and I think they provided the missing key.
Although we are building for ARMv7 (the container the build runs in is an ARMv7 base etc) the underlying hardware performing the build is an ARMv8 CPU which works due to instruction set backwards compatibility. This is probably a bit esoteric but its also out of our control (and has worked well with postgresql and all the other packages we build for years).
If I am correct, postgresql is identifying the CPU of the build system as ARMv8 in that test, and using this rather than the target architecture. Perhaps postgresql configure could look at the target architecture rather than the build system architecture before trying to compile for an unsupported march feature?
Providing CFLAGS for march ARMv7 (e.g CFLAGS='-march=armv7ve+simd') does not change the result of the configure test,. AFAIK other than patching out that commit (which is what we are currently doing) there isn't a way to override configure tests at the command line. Of course I could be missing something, by no means am I an expert in autoconf.
Mathew Heard <mat999@gmail.com> writes:
> The relevant commit we have removed from our build that has returned the
> ability to build is.
> https://github.com/postgres/postgres/commit/5980f1884fc911af120c98ad440b9546ed9012c5
> GCC 12.2.0-3 (latest for debian bullseye)
> Debian Bullseye
> ARMv7 (Allwinner H3)
I spent some time today trying to reproduce this, without success.
One thing I noticed is that Debian 11 seems to have shipped with
gcc 10.2.1, while gcc 12.2.0 comes with Debian 12 (Bookworm).
I don't doubt that you can get gcc 12 for Debian 11, but I wonder
if there's some OS-vs-compiler version skew underlying this issue
for you.
The real question though is how the configure test could succeed
only to get a failure in the main build. If you would get
"undefined reference to `__crc32cb'" etc in the main build,
the configure probe should have failed in the same way.
I tried assorted -march settings with both of those gcc versions
and it acted as-expected for me.
regards, tom lane
