Re: Shared PostgreSQL libraries and symbol versioning

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Pavel Raiskup <praiskup(at)redhat(dot)com>, pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Shared PostgreSQL libraries and symbol versioning
Date: 2018-04-09 21:04:33
Message-ID: 18591.1523307873@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

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.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2018-04-09 21:08:29 Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS
Previous Message Mark Dilger 2018-04-09 20:55:29 Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS