Re: libpq naming on Win64

There is likely to be a long period where many Windows packages for
PostgreSQL are 32 bit only. Due to the way Windows searches for DLLs,
Windows installations of PostgreSQL tend to install libpq.dll into the
bin/ directory of the installation. This will cause obvious problems
with 32 bit packages like pgAdmin which are currently included in that
directory in most installers, to avoid the need to have multiple
copies of DLLs around.

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.

It would also be a nice touch to have the 64 bit MSVC build system
create both the 64 and 32 bit libraries. That would make it much
easier for those of us that need to combine 32 and 64 bit packages
together, saving the pain of building 32 and 64 bit separately.

Thoughts?

--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com

On 5/01/2010 6:52 PM, Dave Page wrote:
> There is likely to be a long period where many Windows packages for
> PostgreSQL are 32 bit only. Due to the way Windows searches for DLLs,
> Windows installations of PostgreSQL tend to install libpq.dll into the
> bin/ directory of the installation. This will cause obvious problems
> with 32 bit packages like pgAdmin which are currently included in that
> directory in most installers, to avoid the need to have multiple
> copies of DLLs around.
>
> 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.

+1 from me. I've had to deal with a few DLLs that may come in either 32-
or 64-bit flavours with the same name, and it's absolutely awful. It
makes debug- and non-debug DLLs with the same names look fun in comparison.

> It would also be a nice touch to have the 64 bit MSVC build system
> create both the 64 and 32 bit libraries. That would make it much
> easier for those of us that need to combine 32 and 64 bit packages
> together, saving the pain of building 32 and 64 bit separately.

Are there plans to move to building with VC++ 2008 at the same time? I'd
be somewhat concerned about building and shipping libp64 with VC++ 2005.

--
Craig Ringer

2010/1/5 Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>:
>> It would also be a nice touch to have the 64 bit MSVC build system
>> create both the 64 and 32 bit libraries. That would make it much
>> easier for those of us that need to combine 32 and 64 bit packages
>> together, saving the pain of building 32 and 64 bit separately.
>
> Are there plans to move to building with VC++ 2008 at the same time? I'd be somewhat concerned about building and shipping libp64 with VC++ 2005.
>

Yes, Magnus has already made that work.

--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com

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 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?

regards, tom lane

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

On tis, 2010-01-05 at 16:48 +0000, Dave Page wrote:
> On Tue, Jan 5, 2010 at 3:15 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > 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.

Can't the installer install things into two separate directories?

On Tuesday, January 5, 2010, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
> On tis, 2010-01-05 at 16:48 +0000, Dave Page wrote:
>> On Tue, Jan 5, 2010 at 3:15 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> > 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.
>
> Can't the installer install things into two separate directories?

Not really. Aside from looking really odd to the end user, the
installer is either running in 64 or 32 bit mode, and Windows may
apply path redirection so the installer doesn't even see the other
path.

Also, given that there are likely to be other 32 bit-only apps using
libpq for quite some time, having both builds will be genuinely
useful.

The only other option that seems feasible might be to have a seperate
bin dir in the main installation directory for 32 bit libraries, but
that'll be pretty ugly. Mind you, on reflection that may be required
if any dependency libraries have the same name.

/D

--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com

Dave Page wrote:
> On Tuesday, January 5, 2010, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
>> On tis, 2010-01-05 at 16:48 +0000, Dave Page wrote:
>>> On Tue, Jan 5, 2010 at 3:15 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>>> 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?

In theory you're now meant to put all shared libraries in the WinSxS
directories, with a given library or group of libraries being stored in
a subdirectory whose filename is a sort of key for the library group.

Apps not only link to the DDL names but also provide an embedded
manifest that tells the linker what versions of those libs it wants. The
linker is meant to look in WinSxS to find the libs. This lets apps link
to specific versions of DLLs without having to play filename games, and
is supposed to let you keep groups of DLLs (say, libpq and its
dependencies) together and ensure they're all loaded together
irrespective of what's on the PATH.

See:

http://msdn.microsoft.com/en-us/library/aa376307%28VS.85%29.aspx

http://msdn.microsoft.com/en-us/library/aa375155%28VS.85%29.aspx

I don't know what the situation is with using WinSxS and manifests with
non-MS compilers or older MS compilers, as I haven't read into this in
much depth.

> Also, given that there are likely to be other 32 bit-only apps using
> libpq for quite some time, having both builds will be genuinely
> useful.

Note that Windows apps are (alas) already used to having to find the
same library under numerous different names. Debug and release versions
(which in Windows are not binary compatible with each other) usually
have different names, so you have to link to different ones depending on
your app configuration. Ditto thread-safe and non-threadsafe for some
libraries. Often the static and shared library versions of a lib will
have different base names too, as in Windows every shared library has a
"stub" static library of the same name that the linker requires when
building against that shared library.

libpq vs libpq64 is unlikely to surprise or horrify any Windows
developer. They're used to much, much, much worse.

--
Craig Ringer

> See:
>
> http://msdn.microsoft.com/en-us/library/aa376307%28VS.85%29.aspx
>
> http://msdn.microsoft.com/en-us/library/aa375155%28VS.85%29.aspx

Oh, and:

http://blogs.msdn.com/jonwis/archive/2005/12/28/507863.aspx

--
Craig Ringer

Dave Page wrote:
> 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.

Maybe I'm missing the point and have a question.

For example, do 32bit psql and the 64bit one have the same name?
If so, where will they be installed?

regards,
Hiroshi Inoue

On Thu, Jan 7, 2010 at 3:58 AM, Hiroshi Inoue <inoue(at)tpf(dot)co(dot)jp> wrote:
> Maybe I'm missing the point and have a question.
>
> For example, do 32bit psql and the 64bit one have the same name?
> If so, where will they be installed?

I'm only talking about libpq. I see no reason to have 32 & 64 bit
versions of other utilities installed in parallel.

--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com

Dave Page wrote:
> On Thu, Jan 7, 2010 at 3:58 AM, Hiroshi Inoue <inoue(at)tpf(dot)co(dot)jp> wrote:
>> Maybe I'm missing the point and have a question.
>>
>> For example, do 32bit psql and the 64bit one have the same name?
>> If so, where will they be installed?
>
> I'm only talking about libpq. I see no reason to have 32 & 64 bit
> versions of other utilities installed in parallel.

Well what about the libraries (e.g openssl) libpq links?

regards,
Hiroshi Inoue

On Thu, Jan 7, 2010 at 12:21 PM, Hiroshi Inoue <inoue(at)tpf(dot)co(dot)jp> wrote:
> Dave Page wrote:
>>
>> On Thu, Jan 7, 2010 at 3:58 AM, Hiroshi Inoue <inoue(at)tpf(dot)co(dot)jp> wrote:
>>>
>>> Maybe I'm missing the point and have a question.
>>>
>>> For example, do 32bit psql and the 64bit one have the same name?
>>> If so, where will they be installed?
>>
>> I'm only talking about libpq. I see no reason to have 32 & 64 bit
>> versions of other utilities installed in parallel.
>
> Well what about the libraries (e.g openssl) libpq links?

Yes, that is an issue as I noted earlier. We probably would still have
to put the 32 bit and 64 bit libraries in a different directory
because of their naming conventions.

--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com