On Sun, Nov 12, 2023 at 12:53 AM Christoph Berg <m...@debian.org> wrote: > Re: Thomas Munro > > In the 13 branch we see that's in the new scan_server_header() > > subroutine where it tries to open the header, after asking pg_config > > --includedir-server where it lives. Hmm... > > It's no ok to use pg_config at test time since `make install` might > not have been called yet: > > https://www.postgresql.org/message-id/2023925.1644591...@sss.pgh.pa.us > https://www.postgresql.org/message-id/YqkV/hoi2sx91...@paquier.xyz
[CC'ing Michael who was involved in that analysis and who also wrote those bits of this commit] We don't have an installation into the final --prefix, but we have tmp_install, surely? And the tests are run with PATH set to point to tmp_install's bin directory. It looks like it did actually find a pg_config executable because otherwise we'd have hit die "could not execute pg_config" and failed sooner. So now I'm wondering if the pg_config it found gives the wrong answer for --includedir-server, because of Debian's local patches that insert a major version into some paths. For example, maybe it's trying to look for access/xlog_internal.h under tmp_install/usr/include/postgresql/server when it's really under tmp_install/usr/include/postgresql/13/server, or vice versa. But then why does that only happen on the salsa build, not on the apt.postgresql.org one?
