static or dynamic libpgport

Поиск
Список
Период
Сортировка
От Andrew Dunstan
Тема static or dynamic libpgport
Дата
Msg-id 4EE2338F.1040302@dunslane.net
обсуждение исходный текст
Ответы 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>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: WIP: SP-GiST, Space-Partitioned GiST
Следующее
От: Peter Geoghegan
Дата:
Сообщение: Re: static or dynamic libpgport