Thread: 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@postnewspapers.com.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 shippinglibp64 with VC++ 2005. > Yes, Magnus has already made that work. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com
Dave Page <dpage@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 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@sss.pgh.pa.us> wrote: > Dave Page <dpage@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. -- 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@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?
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? >> >> 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@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
Dave Page wrote: > On Tue, Jan 5, 2010 at 3:15 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> Dave Page <dpage@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
On Thu, Jan 7, 2010 at 3:58 AM, Hiroshi Inoue <inoue@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
Dave Page wrote: > On Thu, Jan 7, 2010 at 3:58 AM, Hiroshi Inoue <inoue@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. 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@tpf.co.jp> wrote: > Dave Page wrote: >> >> On Thu, Jan 7, 2010 at 3:58 AM, Hiroshi Inoue <inoue@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. > > 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