From: | Dave Page <dpage(at)pgadmin(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: libpq naming on Win64 |
Date: | 2010-01-05 16:48:51 |
Message-ID: | 937d27e11001050848m4eed9e0ft6e6725f665219b0e@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Jan 5, 2010 at 3:15 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Dave Page <dpage(at)pgadmin(dot)org> writes:
>> After chatting with Magnus, we feel that a good solution would be to
>> rename libpq on Win64 to libpq64.dll to distinguish it from the 32 bit
>> equivalent.
>
> Isn't that going to break applications? Where by "break" I mean
> "have to explicitly link with 'libpq64', thereby rendering them
> unportable to any other platform".
I'm really not concerned about that - a build rule to link with the
right library based on pointer size is trivial.
> I would have thought Microsoft would have a better solution than this
> for managing 64-bit libraries. Or am I too optimistic about Redmond's
> competence?
They have two separate installation directories for 32 and 64 bit
packages. With PostgreSQL though, we'll quite possibly be shipping
both 32 and 64 bit components in the same installer, and thus going
into the same installation directory. We may have no choice about
that, as we can't force all the dependent libraries to add 64 bit
support when we need it.
--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Meskes | 2010-01-05 16:53:15 | Re: ECPG SQLDA support |
Previous Message | Kevin Grittner | 2010-01-05 16:48:11 | Re: Testing with concurrent sessions |