Re: static or dynamic libpgport

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: static or dynamic libpgport
Date: 2011-12-12 19:57:28
Message-ID: 1323719848.20924.12.camel@vanquo.pezone.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On fre, 2011-12-09 at 11:13 -0500, Andrew Dunstan wrote:
> Is there any good reason why we shouldn't build and install a dynamic
> libpgport.so?

Just note, if you do this, you need to carefully manage API, ABI,
soname, symbol list, and all that. Every time you tweak configure's
decision about when to include a replacement function, you need to
change the library version. Every time you remove a function, you need
to change the soname. Every backpatched portability fix has the
potential to escalate to a full shared library versioning dance.
Downstream packagers will be delighted, especially if this requires
changing the package name every three minor releases.

To see what this can lead to in the extreme, check the dependencies that
bind has on its internal libraries:

bind9 depends: libbind9-60, libdns69, libisc62, libisccc60, libisccfg62, liblwres60

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2011-12-12 19:58:54 Re: JSON for PG 9.2
Previous Message Kevin Grittner 2011-12-12 19:55:05 Re: [REVIEW] Patch for cursor calling with named parameters