PostgreSQL always uses own versions of *printf(), but does not export them

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

PostgreSQL always uses own versions of *printf(), but does not export them

Patrik Novotny
Hi,

we came across an issue when compiling projects against PostgreSQL
version >=12, as the *printf symbols seems not to be properly
exported.

Build log example:
/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

Are we missing some steps required for building against PostgreSQL
version >=12, or is this an unexpected error?

Also, the issue seems to be related to this commit[1], and more
details can be found in the original Fedora bug report[2].

[1] https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=96bf88d52711ad3a0a4cc2d1d9cb0e2acab85e63
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1849884


Thanks! Regards

Patrik Novotný
Associate Software Engineer
Red Hat
[hidden email]



Reply | Threaded
Open this post in threaded view
|

Re: PostgreSQL always uses own versions of *printf(), but does not export them

Tom Lane-2
Patrik Novotny <[hidden email]> writes:
> we came across an issue when compiling projects against PostgreSQL
> version >=12, as the *printf symbols seems not to be properly
> exported.

Possibly that external code is failing to link with libpgport?
We don't really support external code including our c.h ... but
anything that insists on doing so is very likely going to need
libpgport and/or libpgcommon.

But TBH I'd try to get rid of the inclusion, rather than let the
external code get further into bed with Postgres' internal
portability hacks.  We never have, and we never will, promise
that c.h remains stable across PG versions.

                        regards, tom lane