Recently I attempted to build an external package (pg_bulkload) against
the latest Fedora packages. Unfortunately this fails, as pgxs adds
"-lpgport" to any link line for an executable, and the corresponding
libpgport.a isn't there. And in fact, pg_bulkload does use some of the
functionality there (e.g. pg_strncasecmp), so just stripping "-lpgport"
out doesn't work either.
This happened because Fedora packaging guidelines
<http://fedoraproject.org/wiki/Packaging:Guidelines#Packaging_Static_Libraries>
are strongly against shipping static libraries, and so all the
PostgreSQL static libraries are excluded from the distribution (and I
believe there are similar restrictions for RHEL). Of these libraries, I
believe the only one that is *only* built as a static library is libpgport.
Is there any good reason why we shouldn't build and install a dynamic
libpgport.so?
(Of course, you could say "use the community RPMs", but that would be a
bit of a cop out. Some organizations have a perfectly reasonable policy
or requiring use of vendor packages wherever possible, since vendors are
naturally only going to support packages they provide. So either we
should be arguing to the Fedora/RedHat people that they should ship the
static library, or we should be providing them with a dynamic one, ISTM.)
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
