From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Peter Eisentraut <peter_e(at)gmx(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 20:13:58 |
Message-ID: | 4EE66086.4050800@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 12/12/2011 02:59 PM, Tom Lane wrote:
> Peter Eisentraut<peter_e(at)gmx(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2011-12-12 20:20:39 | Re: foreign key locks, 2nd attempt |
Previous Message | Peter Eisentraut | 2011-12-12 20:04:21 | Re: psql output locations |