[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 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) 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, 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. 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) Thanks, -- Tony Caduto http://www.amsoftwaredesign.com Home of PG Lightning Admin for Postgresql 8.x ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Possible issue with win32 installer(8.1beta 3)...
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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. ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Possible issue with win32 installer(8.1beta 3)...
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 ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Possible issue with win32 installer(8.1beta 3)...
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 ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Possible issue with win32 installer(8.1beta 3)...
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 ---(end of broadcast)--- TIP 6: explain analyze is your friend
