Re: Shared PostgreSQL libraries and symbol versioning - Mailing list pgsql-hackers

On Monday, April 9, 2018 11:04:33 PM CEST Tom Lane wrote:
> Stephen Frost <sfrost@snowman.net> writes:
> > * Peter Eisentraut (peter.eisentraut@2ndquadrant.com) wrote:
> >> On 4/5/18 02:04, Pavel Raiskup wrote:
> >>> As a followup thought; there are probably two major obstacles ATM
> >>> - the DSOs' symbols are not yet versioned, and
> >>> - the build-system doesn't seem to know how to -lpq link against
> >>> external libpq.so
> 
> > I've not looked but neither of those strike me as terribly difficult to
> > overcome, assuming they need to be overcome.
> 
> I'm not excited about introducing YA cross-platform difference in our
> library/linking behavior without fairly strong evidence that it's
> necessary.  The available evidence points in the other direction.

Well, but I believe it is really needed (in our case at least) - it's so
important that we think about doing the symbol versioning downstream-only.
I wouldn't bother you much with this, but it's worth keeping you at least
well informed since - if we moved that direction - there would soon exist
binaries in the wild linked against versioned PG shared libraries, and
those would raise ugly runtime linking warnings if used on systems where
are non-versioned PG libs (it's no problem vice-versa).

As I said, we'd like to provide multiple major PG versions, but only one
set of PG libraries.  But as the time will continue, supporting newer PG
major versions will require updating the system's default 'libpq.so.5',
potentially for the newly added symbols.  If we had in our RPMs versioned
symbols, RPM would for free guard us against wrong package installations
(IOW RPM would guarantee that users won't install packages depending on
newer symbols unless also newer 'libpq.so.5' is installed).  Without
lib symbol versions, there's no **easy** way around this.

Debian folks claim they don't have a problem with symbol versioning even
though they have the same installation pattern since ever, but IMO that's
because (as far as I understand how all of this is done on Debian):

- Debian doesn't have that long support life cycle, so new symbols are
  to occur less likely

- Debian actually provides officially only one version of PG stack
  (including libraries), the rest is provided through postgresql.org
  repositories (one could say "third party", even though those are
  probably the same maintainers).  So for Debian, it's really unlikely to
  build system package against updated 'libpq.so.5' which comes from
  the "third party" repo.

I mean, worthless saying that Debian packaging would benefit from
versioned symbols too (== it would be safe to update system-wide package),
but it would be really awesome to have consistent (upstream blessed) way
to do the versioning.

As for how it would be done downstream-only:  Have a look at the
'symbol-versioning' patch attached.  Sorry for me being verbose here and
there..  It's pretty narrow patch luckily; because the buildsystem is
already GNU ld friendly.  I implemented the new 'exports.txt' parser in
relatively portable /bin/sh, but I can (probably less portably) implement
that in awk too.  Or anything, please tell.

> As for linking against an external .so, commit dddfc4cb2 just went to
> some lengths to make sure that that *wouldn't* happen.  But as long
> as all the builds expect libpq.so to end up in the same place after
> installation, I doubt it matters much what happens at build time.
> You just need to control which build actually installs it.

Agreed, but we can build-time link against system's libpq.so pretty easily
too.  E.g. by something like the attached 'no-libs' patch.  Could we have
something like this as upstream ./configure opt-in?

---
Overall, what are your feelings?  I'd be really glad to go through more
formal patch submission, those attachments are here just to have something more
concrete in hand for the discussion purposes.

Pavel

>             regards, tom lane
>