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

-----Original Message-----
From: pgsql-hackers-owner@postgresql.org
[mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of Tony Caduto
Sent: 17 October 2005 06:43
To: pgsql-hackers@postgresql.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.

Dave Page wrote:

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).

If this were true it would break a huge number of apps, including
buildfarm, which relies on DLLs in the .exe directory being found.

cheers

andrew

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).

If this were true it would break a huge number of apps,
including buildfarm, which relies on DLLs in the .exe
directory being found.

The difference in the latest servicepacks is that no longer is the
*current directory* searched first for DLL files. However, *the
directory of the executable* is still searched.

//Magnus

Magnus Hagander wrote:

If this were true it would break a huge number of apps,
including buildfarm, which relies on DLLs in the .exe
directory being found.

The difference in the latest servicepacks is that no longer is the
*current directory* searched first for DLL files. However, *the
directory of the executable* is still searched.

That's very different from what was stated, and makes far more sense.

cheers

andrew