Re: static or dynamic libpgport

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> On lr, 2011-12-10 at 20:26 -0500, Tom Lane wrote:
>> Right now, libpq laboriously rebuilds all the .o files it needs from
>> src/port/ so as to get them with -fpic. It would be nice if we could
>> clean that up while we're doing this. It might be all right to always
>> build the client-side version of libpgport with -fpic, though I'd be sad
>> if that leaked into the server-side build.

> So would we continue to build the client binaries (psql, pg_dump, etc.)
> against the static libpgport.a, thus keeping it "invisible" there, or
> would we dynamically link them, thus creating a new dependency.

I think that if possible we should avoid creating a new dependency for
either the client binaries or libpq.so itself; what I suggest above
is only a simplification of the build process for libpq. If we create
a new dependency we risk packagers breaking things by forgetting to
include it.

The Fedora/RHEL rule against static libraries is meant to prevent
situations where changes in a library would require rebuilding other
packages to get the fixes in place. If we had to make a quick security
fix in libpq, for example, it would suck if dozens of other packages had
to be rebuilt to propagate the change everywhere. However, I don't think
that concern applies to programs that are in the same source package as
the library --- they'd get rebuilt anyway. So I see nothing wrong with
continuing to statically link these .o files into files belonging to the
postgresql package. It's just that I can't export them in a .a file for
*other* source packages to use.

(Whether a security issue in libpgport is really likely to happen is not
a question that this policy concerns itself with ...)

regards, tom lane