Peter Eisentraut <pete...@gmx.net> writes: > On lör, 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers