Bug 1849884 - PostgreSQL always uses own versions of *printf(), but does not export them
Summary: PostgreSQL always uses own versions of *printf(), but does not export them
Keywords:
Status: ASSIGNED
Alias: None
Product: Fedora
Classification: Fedora
Component: postgresql
Version: 33
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Patrik Novotný
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-06-23 06:29 UTC by Honza Horak
Modified: 2020-08-11 13:39 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
Type: Bug


Attachments (Terms of Use)

Description Honza Horak 2020-06-23 06:29:07 UTC
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.

Comment 1 Patrik Novotný 2020-06-23 11:12:41 UTC
Upstream has been notified. I will update as soon as I get more information.

Comment 2 Patrik Novotný 2020-06-23 14:33:47 UTC
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

Comment 3 Tom Lane 2020-06-23 15:18:03 UTC
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.

Comment 4 Tom Lane 2020-06-23 15:31:12 UTC
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.

Comment 5 Ben Cotton 2020-08-11 13:39:33 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 33 development cycle.
Changing version to 33.


Note You need to log in before you can comment on or make changes to this bug.