libpq naming on Win64
in [PgSql]
|
Prev: global\pg_auth
Next: execute sql commands in core
From: Dave Page on 5 Jan 2010 14:36 On Tuesday, January 5, 2010, Peter Eisentraut <peter_e(a)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(a)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? >> >> 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Craig Ringer on 6 Jan 2010 04:03 Dave Page wrote: > On Tuesday, January 5, 2010, Peter Eisentraut <peter_e(a)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(a)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 -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Craig Ringer on 6 Jan 2010 04:04 > 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Hiroshi Inoue on 6 Jan 2010 22:58 Dave Page wrote: > On Tue, Jan 5, 2010 at 3:15 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: >> Dave Page <dpage(a)pgadmin.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Dave Page on 7 Jan 2010 05:15
On Thu, Jan 7, 2010 at 3:58 AM, Hiroshi Inoue <inoue(a)tpf.co.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |