libpq naming on Win64
in [PgSql]
|
Prev: global\pg_auth
Next: execute sql commands in core
From: Craig Ringer on 5 Jan 2010 09:06 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 -- 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 5 Jan 2010 09:07 2010/1/5 Craig Ringer <craig(a)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 shipping libp64 with VC++ 2005. > Yes, Magnus has already made that work. -- 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: Tom Lane on 5 Jan 2010 10:15 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 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 -- 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 5 Jan 2010 11:48 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. -- 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: Peter Eisentraut on 5 Jan 2010 14:21
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? -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |