Package: postgresql-client-17 Version: 17.0-1+b1 Severity: import Filename: /usr/lib/postgresql/17/lib/pgxs/src/Makefile.global X-Debbugs-Cc: debian-cr...@lists.debian.org User: debian-cr...@lists.debian.org Usertags: ftcbfs Control: affects -1 + src:pg-comparator
Hi, I have one of those weird bugs. It all started when I attempted to cross build pg-comparator for riscv64 and it said: | cc1: error: ‘-fcf-protection=full’ is not supported for this target I looked up the compiler in use and it was riscv64-linux-gnu-gcc as expected and it doesn't understand -fcf-protection=full as expected. That flag is an amd64 (my build architecture) build flag. Just where does it come from? Relatively quickly, I figured that pg_config --pgxs is in use. It simply yields /usr/lib/postgresql/17/lib/pgxs/src/makefiles/pgxs.mk from postgresql-client-17. That file happens to include /usr/lib/postgresql/17/lib/pgxs/src/Makefile.global and that sets CFLAGS such that it includes -fcf-protection=full. Quite simply, a package containing this file has architecture-dependent content and is not eligible for being marked Multi-Arch: foreign. Now clearly, we don't just want to remove the Multi-Arch: foreign marking. Most users of the package really want to use the native one. I think there are now two possible ways forward. One is removing architecture-dependent aspects from contained files. This is not just CFLAGS. TCL_LIB_SPEC contains -L/usr/lib/x86_64-linux-gnu (could simply be dropped at no loss). CFLAGS_CRC contains -msse4.2. python_libdir is /usr/lib/x86_64-linux-gnu. It is far from trivial to remove all of these. The other way is moving this file into an architecture-dependent package. Given its reliance on pg_config, why is it not part of libpq-dev in the first place? Is moving it there an option? Do you happen to know what would break if the file were moved? Helmut
