Re: Shared PostgreSQL libraries and symbol versioning

On Thursday, May 10, 2018 12:41:40 PM CEST Pavel Raiskup wrote:
> On Monday, April 9, 2018 11:04:33 PM CEST Tom Lane wrote:
> > Stephen Frost <sfrost(at)snowman(dot)net> writes:
> > > * Peter Eisentraut (peter(dot)eisentraut(at)2ndquadrant(dot)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.

Gently ping on this; sum-up is that we'll move libpq.so.5 into 'libpq'
package (with corresponding libpq-devel having libpq.so). That package is
likely to receive PG major version updates during one version of
Fedora/CentOS/RHEL version; so because of that the plan is to start symbol
versioning like RHPG_10@@..., e.g. 'PQinitOpenSSL@@RHPG_10'.

I'd go with downstream change now, and I'd like to hear voices against this
change (if there is anything obvious to you). I'd like to help having this
as upstream opt-in of course, too, so feel free to ping me any time in future.

Pavel

> 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
> >
>
>