Dave Page wrote:
> On Tuesday, January 5, 2010, Peter Eisentraut <peter_e@gmx.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@sss.pgh.pa.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