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 <sfr...@snowman.net> writes: > > > * Peter Eisentraut (peter.eisentr...@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.
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 > > > >
