Re: Possible issue with win32 installer(8.1beta 3)...

> -----Original Message-----
> From: pgsql-hackers-owner(at)postgresql(dot)org
> [mailto:pgsql-hackers-owner(at)postgresql(dot)org] On Behalf Of Tony Caduto
> Sent: 17 October 2005 06:43
> To: pgsql-hackers(at)postgresql(dot)org
> Subject: [HACKERS] Possible issue with win32 installer(8.1beta 3)...
>
> Hi,
> I just installed the win32 8.1beta 3 installer on the same PC as my
> client, and I selected not to install PGAdmin III for obvious reasons
> and the installer seemed
> to remove my existing libpq.dll, I went to start up Delphi,
> and got tons
> of errors saying "could not load libpq.dll" did a search for
> libpq.dll
> and sure enough the
> installer blew it away. I am pretty sure it did not have this
> behavior
> before, but I could be wrong.

The 8.1 installer is completely stand-alone and doesn't install any
shared libraries. It certainly won't delete anything that was already
there - that would require us to actively write code to look for and and
remove files, something we purposefully haven't done.

> The installer needs to have a option to install the client libs
> seperately if PGAdmin III is not selected for installation OR
> leave the
> currently installed libs alone OR prompt the
> user that it is going to replace them or remove them. (PG
> Admin III is
> not the only admin program around you know)

The client libraries are installed as a required core component,
regardless of whether you select pgAdmin. It needs to be done this way
because other components such as psqlodbc, pgoledb and even the contrib
module dblink require libpq.

> I would normally just have a copy of libpq.dll in the same dir as my
> exe, but with the latest XP service packs this does not work anymore,

It should do - in fact we package 8.1 in exactly that way after
extensive testing on XP SP2 as well as 2K3 SP1 (not to mention older
platforms).

> not to mention
> libpq.dll seems to have several dependencies that also must be in
> system32 i.e. libpq.dll seems to have these dependencies hard
> coded to
> system32, because if I remove the dependencies from system32 and put
> them the same dir as my exe, I get libpq errors saying it can't find
> libiconv-2.dll libintl-2.dll even though they are in the same dir.

When we build the installer it's tested on a number of clean
installations of Windows before release. Just to be sure, I just double
checked it on a clean Windows 2K3 Enterprise Server, with SP1 + patches
that I happen to be configuring at the moment. All the libraries are
found, even though none are in any shared locations (they're all in
C:\Program Files\PostgreSQL-8.1-beta3\bin).

For info, libpq requires

libiconv-2.dll
libintl-2.dll
libeay32.dll
ssleay32.dll
Comerr32.dll
krb5_32.dll

> Can't these two dependencies be staticly linked into
> libpq.dll to ease
> deployment issues? If libpq.dll was all self contained, I
> could rename
> it to something just my app could use and then I would not
> have to worry
> about the server setup blowing away libpq.dll. Who would care
> if it made
> the dll bigger? you have to deploy all the files anyway. (I
> don't know
> any thing about C, so I can't try myself)

*If* each of those sub project were easily compilable in static mode on
Windows then that would probably be possible, given a few extra hours in
the day. As it is, most have very limited support for Windows, and often
finding a way to build a normal dynamic version is hard enough.

Regards, Dave.