static or dynamic libpgport - Mailing list pgsql-hackers

From Andrew Dunstan
Subject static or dynamic libpgport
Date
Msg-id 4EE2338F.1040302@dunslane.net
Whole thread Raw
Responses Re: static or dynamic libpgport  (Peter Geoghegan <peter@2ndquadrant.com>)
Re: static or dynamic libpgport  (Steve Singer <ssinger@ca.afilias.info>)
Re: static or dynamic libpgport  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers
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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: WIP: SP-GiST, Space-Partitioned GiST
Next
From: Peter Geoghegan
Date:
Subject: Re: static or dynamic libpgport