From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, Bruce Momjian <bruce(at)momjian(dot)us>, Steve Singer <ssinger(at)ca(dot)afilias(dot)info>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: static or dynamic libpgport |
Date: | 2011-12-12 19:59:41 |
Message-ID: | 24195.1323719981@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2011-12-12 20:04:21 | Re: psql output locations |
Previous Message | Robert Haas | 2011-12-12 19:58:54 | Re: JSON for PG 9.2 |