PostgreSQL always uses own versions of *printf(), but does not export them
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]https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=96bf88d52711ad3a0a4cc2d1d9cb0e2acab85e63, and more
details can be found in the original Fedora bug report[2]https://bugzilla.redhat.com/show_bug.cgi?id=1849884.
[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
panovotn@redhat.com
Patrik Novotny <panovotn@redhat.com> 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