Re: static or dynamic libpgport
Andrew Dunstan <andrew@dunslane.net>
From: Andrew Dunstan <andrew@dunslane.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Peter Eisentraut <peter_e@gmx.net>, Bruce Momjian <bruce@momjian.us>, Steve Singer <ssinger@ca.afilias.info>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2011-12-12T20:13:58Z
Lists: pgsql-hackers
On 12/12/2011 02:59 PM, Tom Lane wrote: > Peter Eisentraut<peter_e@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. > > OK, I'll work on this basis. The downside is that we'll be building it but not using it, but I can see the advantages. cheers andrew