On 12/09/2011 01:01 PM, Steve Singer wrote:
On 11-12-09 11:13 AM, Andrew Dunstan wrote:
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?
+1
We've struggled with slony and pgport because so many users have had
problems with pgport not being included in some distributions. It has
some useful functions, I think recent versions of slony use it on
win32 but don't elsewhere. Wee have had at least one patch floating
around that makes conditionally includes certain small behaviours in
slony based on if pgport is available or not based on a configure check.
What package would a shared static pgport be installed with? Slony
requires a server + headers to build but slon and slonik only have a
runtime dependency on libpq (I don't know if anyone installs
slon/slonik on a machine without a postgresql server but you could)
In the Fedora world, a static lib would go in postgresql-devel, but a
dynamic lib would go in postgresql-libs, which is also where libpq is
shipped.
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
