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

Re: Helmut Grohne

pg_config used to be in postgresql-server-dev-NN, but since PG
extension autopkgtests need $(shell pg_config --pgxs), I moved
pg_config and pgxs.mk into postgresql-client-NN so the tests don't
pull in postgresql-server-dev-NN with its clang dependencies. Also, it
seemed to be a good move in general to have pg_config available in the
default install on PG servers.

It can't go into libpq-dev because libpq-dev is independent from the
PG major version. (There *is* a pg_config in libpq-dev, but it gets
dpkg-diverted away by postgresql-common, i.e. on server installs.)

Perhaps we could throw a 3rd copy of pg_config into
postgresql-server-dev-NN (which isn't MA) and prefer that over the one
from postgresql-client-NN?

How much does cross-compiling PG things work if you fix the compiler
flag bit? My last info was that there were more bits missing. If this
is the last one, I'll gladly work on a fix.

Christoph

Hi Christoph,

I note that postgresql-server-dev-NN was not M-A:foreign. So the move
that you describe here is what caused the bug report at hand (while at
the same time improving other aspects).

Thanks for clarifying.
that pg_config should not be part of any package that is marked
Multi-Arch: foreign. In the perl world, we were faced with a problem
that looks vaguely related to me. What we ended up doing there was
adding a virtual package perl-xs-dev. Then, we gradually switched over
all source packages building perl architecture-dependent perl extension
modules to build-depend on this. The take-away here is that the
functionality required for building extensions is now captured in a
separate name and allows reorganizing the perl source without incurring
subsequent changes to all perl extensions. The addition of a virtual
package (that may become real later) also means that we can make the
transition soft for downstreams: Add the provides to postgresql-client
now, transition rdeps, then reorganize without disrupting many
consumers.

As far as I understand it, pg_config is very architecture-dependent. It
isn't just one aspect and we'd be done. To make matters worse, pg_config
also is an ELF executable. Hence we have a choice between producing
results for the wrong architecture (status quo) and not being able to
run it at all. My main approach for improving cross building of postgres
reverse dependencies has been patching out uses of pg_config in favour
of pkg-config (where feasible), but pg_config --pgxs doesn't work at
similar ease. I have no solution to offer here.

So as unfortunate as this may be, pg_config technically poses a
violation of Multi-Arch: foreign. It should not reside in a package
marked M-A:foreign and fixing this bug will likely not improve cross
building in any practical way (except maybe for making it fail faster).

A vague option I see on the horizon would be changing the pgxs.mk
Makefile to prefer use of pkgconf over using pg_config. Then, a user may
set the PKG_CONFIG variable to determine the host architecture and then
include pgxs.mk picking up values for the desired architecture. However,
the present libpq.pc does not answer all the questions that pg_config
answers now (e.g. --mandir), so we're looking at a deeper rabbit hole.

Helmut