Description of problem:
Previously consulted in https://src.fedoraproject.org/rpms/libpq/pull-request/3
Opening this BZ to track it properly until it is made clear with upstream.
Version-Release number of selected component (if applicable):
postgresql 12+, libpq 12+
when compiling source against PostgreSQL
Steps to Reproduce:
1. compile gambas3 without https://src.fedoraproject.org/rpms/gambas3/pull-request/1 applied
Errors in the build.log:
/builddir/build/BUILDROOT/gambas3-3.14.3-3.fc33.x86_64/usr/bin/gbi3: symbol lookup error: /builddir/build/BUILDROOT/gambas3-3.14.3-3.fc33.x86_64/usr/lib64/gambas3/gb.db.postgresql.so: undefined symbol: pg_fprintf
This looks like the upstream issue that caused this:
I found a similar issue in other package, repmgr, and they solved it like this:
It seems to work as a work-around for gambas3 as well.
However, it looks like this would deserve a discussion on postgresql upstream, i.e. discuss what was the suggested way of compiling the other projects with libpq with that change. The commit does not mention the compiling issues, so it might likely be an unexpected side-effect.
Upstream has been notified. I will update as soon as I get more information.
So as for the upstream response; the issue might be in that the external code is failing to link with libpgport and/or libpgcommon. However, it has been noted that such usage of PostgreSQL libraries by any external code is not supported (nor really recommended) by upstream. See the original response.
I poked around in the gambas3 sources, and I'd recommend reclassifying this as a gambas3 bug. I find this
libpq-fe.h is the only one of those that we promise much cross-version stability for. In particular the immediate build fail is from including postgres.h without supporting that with libraries. But as I mentioned to Patrik, you don't really want to go down that road, it will just result in more problems in the future.
I think the reason postgres.h is being included here is that the code needs some type OID constants (BOOLOID etc), and it thinks it has to get them from pg_type.h, which requires postgres.h. That was true years ago, but since PG v11 there's a better way. I think the right fix is to reduce these inclusions to
(you might want to adjust the list of headers that the configure.ac file in the parent directory looks for, too). I haven't actually tried that, but unless main.c is poking into stuff that it *really* shouldn't be messing with, that should be a sufficient set of inclusions. This route will be far less subject to cross-version breakage.
Further to that: it looks like the next dozen or so lines in main.c could also be dispensed with:
I think this is just getting rid of some macros that postgres.h provided but gambas3 already found they couldn't tolerate.
The fix I recommend will result in a *lot* less namespace pollution.
This bug appears to have been reported against 'rawhide' during the Fedora 33 development cycle.
Changing version to 33.