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+ How reproducible: when compiling source against PostgreSQL Steps to Reproduce: 1. compile gambas3 without https://src.fedoraproject.org/rpms/gambas3/pull-request/1 applied Actual results: 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 Expected results: No errors Additional info: This looks like the upstream issue that caused this: https://github.com/postgres/postgres/commit/96bf88d5271 I found a similar issue in other package, repmgr, and they solved it like this: https://github.com/2ndQuadrant/repmgr/commit/1ed8b1067abb641af138a28906d65ded572c4ad1 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[1]; 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[1]. [1] https://www.postgresql-archive.org/PostgreSQL-always-uses-own-versions-of-printf-but-does-not-export-them-td6142811.html
I poked around in the gambas3 sources, and I'd recommend reclassifying this as a gambas3 bug. I find this in gb.db.postgresql/src/main.c: #include <libpq-fe.h> #include <postgres.h> #include <pg_type.h> 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 #include <libpq-fe.h> #include <pg_type_d.h> (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: #ifdef PACKAGE_NAME #undef PACKAGE_NAME #undef PACKAGE_BUGREPORT #undef PACKAGE_STRING #undef PACKAGE_TARNAME #undef PACKAGE_VERSION #undef PACKAGE_URL #endif #ifdef Max #undef Max #endif #ifdef Min #undef Min #endif 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.
This package has changed maintainer in Fedora. Reassigning to the new maintainer of this component.
This message is a reminder that Fedora 33 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 33 on 2021-11-30. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '33'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 33 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 33 changed to end-of-life (EOL) status on 2021-11-30. Fedora 33 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.