Thread: msvcr80.dll and PostgreSQL 8.3 under Windows XP
Hi, I installed today's release setup of PostgreSQL 8.3. Unfortunately Libpq.dll has a dependancy to msvcr80.dll, which can't be found on my system. I checked the msi installer file and found that this dll will not be installed under Windows XP. Does anyone has any suggestions concerning this serious problem? Thanks for your help, Hermann
Hi. It seems that MSVCR80.dll is not registered to InstallFinalize on the problem of the timing of an installer. It is not found at the time of initdb. Therefore, please before install this. http://www.microsoft.com/downloads/details.aspx?FamilyID=200b2fd9-ae1a-4a14-984d-389c36f85647&DisplayLang=en The adjustment of Installer may be necessity. It must consider many situations. However, The solution method was not found even in MSDN....It seems that what is used in the middle of install can't be execute. to Dave. Did you already find the solution method? Regards, Hiroshi Saito ----- Original Message ----- From: "Hermann Muster" <Hermann.Muster@gmx.de> To: <pgsql-general@postgresql.org> Sent: Monday, February 04, 2008 11:43 PM Subject: [GENERAL] msvcr80.dll and PostgreSQL 8.3 under Windows XP > Hi, > > I installed today's release setup of PostgreSQL 8.3. Unfortunately > Libpq.dll has a dependancy to msvcr80.dll, which can't be found on my > system. > > I checked the msi installer file and found that this dll will not be > installed under Windows XP. > > Does anyone has any suggestions concerning this serious problem? > > Thanks for your help, > Hermann > > ---------------------------(end of broadcast)--------------------------- > TIP 2: Don't 'kill -9' the postmaster
Konbanwa Hiroshi-san, thanks for your fast reply. I installed the Microsoft Visual C++ 2005 SP1 Redistributable Package (x86) before running the PostgreSQL 8.3 setup. However, the PostgreSQL installation does still not find the msvcr80.dll. It seems, that the PostgreSQL setup has to be adjusted or is there any other possibility to get it working under XP? Background is that our application's setup is installing it's database on PostgreSQL and can't completely do that with the dll missing. Greetings, Hermann Hiroshi Saito schrieb: > Hi. > > It seems that MSVCR80.dll is not registered to InstallFinalize on the > problem of the timing of an installer. > It is not found at the time of initdb. Therefore, please before install > this. > http://www.microsoft.com/downloads/details.aspx?FamilyID=200b2fd9-ae1a-4a14-984d-389c36f85647&DisplayLang=en > > > The adjustment of Installer may be necessity. It must consider many > situations. However, The solution method was not found even in > MSDN....It seems that what is used in the middle of install can't be > execute. > > to Dave. > Did you already find the solution method? > Regards, > Hiroshi Saito > > ----- Original Message ----- From: "Hermann Muster" <Hermann.Muster@gmx.de> > To: <pgsql-general@postgresql.org> > Sent: Monday, February 04, 2008 11:43 PM > Subject: [GENERAL] msvcr80.dll and PostgreSQL 8.3 under Windows XP > > >> Hi, >> >> I installed today's release setup of PostgreSQL 8.3. Unfortunately >> Libpq.dll has a dependancy to msvcr80.dll, which can't be found on my >> system. >> >> I checked the msi installer file and found that this dll will not be >> installed under Windows XP. >> >> Does anyone has any suggestions concerning this serious problem? >> >> Thanks for your help, >> Hermann >> >> ---------------------------(end of broadcast)--------------------------- >> TIP 2: Don't 'kill -9' the postmaster > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Have you searched our list archives? > > http://archives.postgresql.org/ >
On Feb 4, 2008 3:38 PM, Hiroshi Saito <z-saito@guitar.ocn.ne.jp> wrote: > Hi. > > It seems that MSVCR80.dll is not registered to InstallFinalize on the problem of the timing of an installer. > It is not found at the time of initdb. Therefore, please before install this. > http://www.microsoft.com/downloads/details.aspx?FamilyID=200b2fd9-ae1a-4a14-984d-389c36f85647&DisplayLang=en > > The adjustment of Installer may be necessity. It must consider many situations. However, The solution > method was not found even in MSDN....It seems that what is used in the middle of install can't be execute. > > to Dave. > Did you already find the solution method? I haven't been looking for one. One of my standard tests when releasing a new version is to try an iinstall on a clean copy of XP. I've just re-tested that to be sure and I see the installer copying the runtimes, and everything works just fine afterwards. As an additional test, I tried to execute a copy of psql.exe. Before running the installer it simply exited with 'The system cannot execute the specified program' (which is the normal message if the runtimes cannot be found), but after I ran the installer, the same copy of psql popped up a message box saying it couldn't find an SSL library (to be expected - I didn't copy it) - that tells me it could then find the runtimes. So, is there some reason the runtimes might not install in non-English versions of Windows? We're using the Windows Installer merge module as per Microsoft's recommendations. Regards, Dave.
Hi. Umm, Please investigate msm under the following. C:\Program Files\Common Files\Merge Modules Microsoft_VC80_CRT_x86.msm Please investigate the date and size of that.? Regards, Hiroshi Saito ----- Original Message ----- From: "Hermann Muster" <Hermann.Muster@gmx.de> > Konbanwa Hiroshi-san, > > thanks for your fast reply. I installed the Microsoft Visual C++ 2005 > SP1 Redistributable Package (x86) before running the PostgreSQL 8.3 > setup. However, the PostgreSQL installation does still not find the > msvcr80.dll. > > It seems, that the PostgreSQL setup has to be adjusted or is there any > other possibility to get it working under XP? Background is that our > application's setup is installing it's database on PostgreSQL and can't > completely do that with the dll missing. > > Greetings, > Hermann > > > Hiroshi Saito schrieb: >> Hi. >> >> It seems that MSVCR80.dll is not registered to InstallFinalize on the >> problem of the timing of an installer. >> It is not found at the time of initdb. Therefore, please before install >> this. >> http://www.microsoft.com/downloads/details.aspx?FamilyID=200b2fd9-ae1a-4a14-984d-389c36f85647&DisplayLang=en >> >> >> The adjustment of Installer may be necessity. It must consider many >> situations. However, The solution method was not found even in >> MSDN....It seems that what is used in the middle of install can't be >> execute. >> >> to Dave. >> Did you already find the solution method? >> Regards, >> Hiroshi Saito >> >> ----- Original Message ----- From: "Hermann Muster" <Hermann.Muster@gmx.de> >> To: <pgsql-general@postgresql.org> >> Sent: Monday, February 04, 2008 11:43 PM >> Subject: [GENERAL] msvcr80.dll and PostgreSQL 8.3 under Windows XP >> >> >>> Hi, >>> >>> I installed today's release setup of PostgreSQL 8.3. Unfortunately >>> Libpq.dll has a dependancy to msvcr80.dll, which can't be found on my >>> system. >>> >>> I checked the msi installer file and found that this dll will not be >>> installed under Windows XP. >>> >>> Does anyone has any suggestions concerning this serious problem? >>> >>> Thanks for your help, >>> Hermann >>> >>> ---------------------------(end of broadcast)--------------------------- >>> TIP 2: Don't 'kill -9' the postmaster >> >> ---------------------------(end of broadcast)--------------------------- >> TIP 4: Have you searched our list archives? >> >> http://archives.postgresql.org/ >> > > ---------------------------(end of broadcast)--------------------------- > TIP 1: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly
Hi. ----- Original Message ----- From: "Dave Page" <dpage@postgresql.org> > So, is there some reason the runtimes might not install in non-English > versions of Windows? We're using the Windows Installer merge module as > per Microsoft's recommendations. Surely your examination is passed. Therfore, It may be the problem of some languages. However, It seems that MSVCR80 also has the version problem. Furthermore, the problem was seen by VISTA...but but, I did not have a spare time.... Anyway, If there are again in addition to this situation, we need investigation deep as a clear problem. Regards, Hiroshi Saito
There's at least one website out there that offers DLLs for download, but I have no idea whether this is legal or not. Can anyone comment? Ray. --------------------------------------------------------------- Raymond O'Donnell, Director of Music, Galway Cathedral, Ireland rod@iol.ie ---------------------------------------------------------------
On Feb 4, 2008, at 9:37 AM, Raymond O'Donnell wrote: > There's at least one website out there that offers DLLs for > download, but I have no idea whether this is legal or not. Can > anyone comment? It's the C runtime. IIRC that's one of the redistributables, so it's OK to distribute. Cheers, Steve
Hi. MSVCR80.dll which the binary of 8.3 refers to is this. C:\WINDOWS\WinSxS\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.762_x-ww_6b128700\MSVCR80.dll I tried again in the beautiful environment which does not have 8.0.50727.762 in the environment of XP-SP2. Then, It was fine. I can't remember the environment which received the report by RC2.?_? It is likely to be necessary to investigate the environment of Hermann-san. P.S) However, It seems that a VISTA user's problem remains. Regards, Hiroshi Saito ----- Original Message ----- From: "Hiroshi Saito" <z-saito@guitar.ocn.ne.jp> > Hi. > > Umm, Please investigate msm under the following. > C:\Program Files\Common Files\Merge Modules > Microsoft_VC80_CRT_x86.msm > > Please investigate the date and size of that.? > > Regards, > Hiroshi Saito > > ----- Original Message ----- > From: "Hermann Muster" <Hermann.Muster@gmx.de> > > >> Konbanwa Hiroshi-san, >> >> thanks for your fast reply. I installed the Microsoft Visual C++ 2005 >> SP1 Redistributable Package (x86) before running the PostgreSQL 8.3 >> setup. However, the PostgreSQL installation does still not find the >> msvcr80.dll. >> >> It seems, that the PostgreSQL setup has to be adjusted or is there any >> other possibility to get it working under XP? Background is that our >> application's setup is installing it's database on PostgreSQL and can't >> completely do that with the dll missing. >> >> Greetings, >> Hermann >> >> >> Hiroshi Saito schrieb: >>> Hi. >>> >>> It seems that MSVCR80.dll is not registered to InstallFinalize on the >>> problem of the timing of an installer. >>> It is not found at the time of initdb. Therefore, please before install >>> this. >>> http://www.microsoft.com/downloads/details.aspx?FamilyID=200b2fd9-ae1a-4a14-984d-389c36f85647&DisplayLang=en >>> >>> >>> The adjustment of Installer may be necessity. It must consider many >>> situations. However, The solution method was not found even in >>> MSDN....It seems that what is used in the middle of install can't be >>> execute. >>> >>> to Dave. >>> Did you already find the solution method? >>> Regards, >>> Hiroshi Saito >>> >>> ----- Original Message ----- From: "Hermann Muster" <Hermann.Muster@gmx.de> >>> To: <pgsql-general@postgresql.org> >>> Sent: Monday, February 04, 2008 11:43 PM >>> Subject: [GENERAL] msvcr80.dll and PostgreSQL 8.3 under Windows XP >>> >>> >>>> Hi, >>>> >>>> I installed today's release setup of PostgreSQL 8.3. Unfortunately >>>> Libpq.dll has a dependancy to msvcr80.dll, which can't be found on my >>>> system. >>>> >>>> I checked the msi installer file and found that this dll will not be >>>> installed under Windows XP. >>>> >>>> Does anyone has any suggestions concerning this serious problem? >>>> >>>> Thanks for your help, >>>> Hermann >>>> >>>> ---------------------------(end of broadcast)--------------------------- >>>> TIP 2: Don't 'kill -9' the postmaster >>> >>> ---------------------------(end of broadcast)--------------------------- >>> TIP 4: Have you searched our list archives? >>> >>> http://archives.postgresql.org/ >>> >> >> ---------------------------(end of broadcast)--------------------------- >> TIP 1: if posting/reading through Usenet, please send an appropriate >> subscribe-nomail command to majordomo@postgresql.org so that your >> message can get through to the mailing list cleanly > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Have you searched our list archives? > > http://archives.postgresql.org/
On Feb 4, 2008 6:37 PM, Hiroshi Saito <z-saito@guitar.ocn.ne.jp> wrote: > Hi. > > MSVCR80.dll which the binary of 8.3 refers to is this. > C:\WINDOWS\WinSxS\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.762_x-ww_6b128700\MSVCR80.dll > I tried again in the beautiful environment which does not have 8.0.50727.762 in the environment of XP-SP2. > Then, It was fine. I can't remember the environment which received the report by RC2.?_? > It is likely to be necessary to investigate the environment of Hermann-san. Yes - Hermann; can you elaborate on your system please? Service pack level, language etc. etc. > However, It seems that a VISTA user's problem remains. Sorry, which Vista problem? /D
Dave Page schrieb: > On Feb 4, 2008 6:37 PM, Hiroshi Saito <z-saito@guitar.ocn.ne.jp> wrote: >> Hi. >> >> MSVCR80.dll which the binary of 8.3 refers to is this. >> C:\WINDOWS\WinSxS\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.762_x-ww_6b128700\MSVCR80.dll >> I tried again in the beautiful environment which does not have 8.0.50727.762 in the environment of XP-SP2. >> Then, It was fine. I can't remember the environment which received the report by RC2.?_? >> It is likely to be necessary to investigate the environment of Hermann-san. > > Yes - Hermann; can you elaborate on your system please? Service pack > level, language etc. etc. > >> However, It seems that a VISTA user's problem remains. > > Sorry, which Vista problem? > > /D > > ---------------------------(end of broadcast)--------------------------- > TIP 6: explain analyze is your friend > I'm using a clean Virtual PC Image of a German Windows XP SP2. I also checked the folder C:\Program Files\Common Files\Merge Modules Microsoft_VC80_CRT_x86.msm which is not available on my system. C:\WINDOWS\WinSxS\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.762_x-ww_6b128700\MSVCR80.dll is however exactly there on my system. But Dependancy Walker still does not find the MSVCR80.dll. Do you need any other information from me? Regards, Hermann
On Feb 5, 2008 7:52 AM, Hermann Muster <Hermann.Muster@gmx.de> wrote: > I'm using a clean Virtual PC Image of a German Windows XP SP2. OK - I've been testing on a clean English XP Pro SP2. > I also checked the folder C:\Program Files\Common Files\Merge Modules > Microsoft_VC80_CRT_x86.msm which is not available on my system. It wouldn't be - that file is the merge module we build into the installer, and unless you have a non-Express version of Visual C++ you won't have it. It'll get unpacked into the files we need upon installation. > C:\WINDOWS\WinSxS\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.762_x-ww_6b128700\MSVCR80.dll > is however exactly there on my system. But Dependancy Walker still does > not find the MSVCR80.dll. Thats where it is on my machine. Looking at the Microsoft notes (http://msdn2.microsoft.com/en-us/library/ms235290.aspx) - it makes the point that the installation will fail for non-administrators, and the dependent apps then won't work. I don't suppose you have power user rights but not full administrator rights in user account you're using? Regards,. Dave
On Feb 13, 2008 3:05 PM, Hermann Muster <Hermann.Muster@gmx.de> wrote: > Dave Page schrieb: > > On Feb 5, 2008 7:52 AM, Hermann Muster <Hermann.Muster@gmx.de> wrote: > >> I also checked the folder C:\Program Files\Common Files\Merge Modules > >> Microsoft_VC80_CRT_x86.msm which is not available on my system. > >> > > > > It wouldn't be - that file is the merge module we build into the > > installer, and unless you have a non-Express version of Visual C++ you > > won't have it. It'll get unpacked into the files we need upon > > installation. > > > Where will it be unpacked? Into the PostgreSQL application directory? As > we are using similar systems, can you tell me if the dll is successfully > installed on your system? The merge module? Into the directory you already checked: > >> C:\WINDOWS\WinSxS\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.762_x-ww_6b128700\MSVCR80.dll > The user I'm trying to install it with is an user with full > administrator rights. I hope you can help me with this issue, as besides > other issues concerning PostgreSQL 8.3 we could solve on our own, this > one is the last thing preventing us to release our application with > PostgreSQL 8.3 support. My best guess at the moment is that something is borked on your system. I've spent most of the week testing various methods of installing the runtimes and the one that has worked every time without fail is the Microsoft installer that Hiroshi-san suggested you try. I would suggest re-running that, but with a slightly more inventive commandline - eg, something like: vcredist_x86.exe /q:a /c:"VCREDI~1.EXE /q:a /c:""msiexec /i vcredist.msi REINSTALLMODE=vamus REINSTALL=ALL /qb /l*v vcredist_install.log"" " What that /should/ do, is run the MSI installer (which is buried inside two, count 'em, two .exe wrappers!) in full reinstall *everything* mode, and create a nice verbose logfile so we can see if anything fails. Once thats reinstalled, try running the PG installer again (also with logging enabled), and if it still doesn't work, we can start looking at the logfiles. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com The Oracle-compatible database company
Dave Page schrieb: > On Feb 13, 2008 3:05 PM, Hermann Muster <Hermann.Muster@gmx.de> wrote: > >> Dave Page schrieb: >> >>> On Feb 5, 2008 7:52 AM, Hermann Muster <Hermann.Muster@gmx.de> wrote: >>> >>>> I also checked the folder C:\Program Files\Common Files\Merge Modules >>>> Microsoft_VC80_CRT_x86.msm which is not available on my system. >>>> >>>> >>> It wouldn't be - that file is the merge module we build into the >>> installer, and unless you have a non-Express version of Visual C++ you >>> won't have it. It'll get unpacked into the files we need upon >>> installation. >>> >>> >> Where will it be unpacked? Into the PostgreSQL application directory? As >> we are using similar systems, can you tell me if the dll is successfully >> installed on your system? >> > > The merge module? Into the directory you already checked: > > >>>> C:\WINDOWS\WinSxS\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.762_x-ww_6b128700\MSVCR80.dll >>>> > > >> The user I'm trying to install it with is an user with full >> administrator rights. I hope you can help me with this issue, as besides >> other issues concerning PostgreSQL 8.3 we could solve on our own, this >> one is the last thing preventing us to release our application with >> PostgreSQL 8.3 support. >> > > My best guess at the moment is that something is borked on your > system. I've spent most of the week testing various methods of > installing the runtimes and the one that has worked every time without > fail is the Microsoft installer that Hiroshi-san suggested you try. > > I would suggest re-running that, but with a slightly more inventive > commandline - eg, something like: > > vcredist_x86.exe /q:a /c:"VCREDI~1.EXE /q:a /c:""msiexec /i > vcredist.msi REINSTALLMODE=vamus REINSTALL=ALL /qb /l*v > vcredist_install.log"" " > > What that /should/ do, is run the MSI installer (which is buried > inside two, count 'em, two .exe wrappers!) in full reinstall > *everything* mode, and create a nice verbose logfile so we can see if > anything fails. > > Once thats reinstalled, try running the PG installer again (also with > logging enabled), and if it still doesn't work, we can start looking > at the logfiles. > > Hi Dave, after testing several combinations I can tell you following, because maybe I couldn't make clear what my problem is. The msvcr80.dll is correctly installed in the C:\WINDOWS\WinSxS\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.762_x-ww_6b128700 respective the C:\WINDOWS\WinSxS\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.163_x-ww_681e29fb folder for my german version of Windows XP. What I don't understand is why the msvcr80.dll is not copied to the PostgreSQL\8.3\bin directory by the PostgreSQL 8.3 setup. Because when I check the libpq.dll with the Dependancy Viewer, the msvcr80.dll can not be found, however it is installed in the above two folders. And that's where my application comes into play. The libpq.dll can't be used because it does not find the msvcr80.dll. Did you check on that before? Can you load this library? Thanks for your help. Regards, Hermann
On Feb 18, 2008 10:05 AM, Hermann Muster <Hermann.Muster@gmx.de> wrote: > Hi Dave, > > after testing several combinations I can tell you following, because > maybe I couldn't make clear what my problem is. The msvcr80.dll is > correctly installed in the > C:\WINDOWS\WinSxS\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.762_x-ww_6b128700 > respective the > C:\WINDOWS\WinSxS\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.163_x-ww_681e29fb > folder for my german version of Windows XP. > > What I don't understand is why the msvcr80.dll is not copied to the > PostgreSQL\8.3\bin directory by the PostgreSQL 8.3 setup. Because it's not supposed to be. > Because when I > check the libpq.dll with the Dependancy Viewer, the msvcr80.dll can not > be found, however it is installed in the above two folders. And that's > where my application comes into play. The libpq.dll can't be used > because it does not find the msvcr80.dll. Did you check on that before? > Can you load this library? Yes - if the runtimes are *properly* installed, any application should be able to find them in the winsxs folder - thats how Microsoft designed it to work. Did you try doing what I asked in my previous message? -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com The Oracle-compatible database company
Dave Page schrieb: > On Feb 18, 2008 10:05 AM, Hermann Muster <Hermann.Muster@gmx.de> wrote: > >> Hi Dave, >> >> after testing several combinations I can tell you following, because >> maybe I couldn't make clear what my problem is. The msvcr80.dll is >> correctly installed in the >> C:\WINDOWS\WinSxS\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.762_x-ww_6b128700 >> respective the >> C:\WINDOWS\WinSxS\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.163_x-ww_681e29fb >> folder for my german version of Windows XP. >> >> What I don't understand is why the msvcr80.dll is not copied to the >> PostgreSQL\8.3\bin directory by the PostgreSQL 8.3 setup. >> > > Because it's not supposed to be. > > >> Because when I >> check the libpq.dll with the Dependancy Viewer, the msvcr80.dll can not >> be found, however it is installed in the above two folders. And that's >> where my application comes into play. The libpq.dll can't be used >> because it does not find the msvcr80.dll. Did you check on that before? >> Can you load this library? >> > > Yes - if the runtimes are *properly* installed, any application should > be able to find them in the winsxs folder - thats how Microsoft > designed it to work. > > Did you try doing what I asked in my previous message? > > I finally found the problem. I unfortunately used an "very" old version of Dependency Walker which couldn't handle the libpq.dll and always showed that the msvcr80.dll is missing. After installing PostgreSQL 8.3 and updating the Dependency Walker, everything seems to be fine and my application can use the libpq.dll. Will test it again in the next days. However, one question remains. On my clean Virtual PC Image, there is already a folder "C:\WINDOWS\WinSxS\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.163_x-ww_681e29fb" containing the msvcr80.dll. After installing PostgreSQL or the runtimes, there is another folder "C:\WINDOWS\WinSxS\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.762_x-ww_6b128700". But only the path of the dll installed with the runtimes is recognized. Does that mean our customers have to install the runtimes at all costs? That would be the case if our application is running on a client, not the server PostgreSQL is installed on? Thanks again. Regards, Hermann
On Feb 18, 2008 3:11 PM, Hermann Muster <Hermann.Muster@gmx.de> wrote: > I finally found the problem. I unfortunately used an "very" old version > of Dependency Walker which couldn't handle the libpq.dll and always > showed that the msvcr80.dll is missing. After installing PostgreSQL 8.3 > and updating the Dependency Walker, everything seems to be fine and my > application can use the libpq.dll. Will test it again in the next days. Good :-) > However, one question remains. On my clean Virtual PC Image, there is > already a folder > "C:\WINDOWS\WinSxS\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.163_x-ww_681e29fb" > containing the msvcr80.dll. After installing PostgreSQL or the runtimes, > there is another folder > "C:\WINDOWS\WinSxS\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.762_x-ww_6b128700". > But only the path of the dll installed with the runtimes is recognized. > Does that mean our customers have to install the runtimes at all costs? > That would be the case if our application is running on a client, not > the server PostgreSQL is installed on? Microsoft have changed things so that you now have multiple versions of the runtimes installed side by side without them conflicting with one another - we use the latest (SP1) version (8.0.50727.762) with PostgreSQL - something else has presumably added the earlier verison you also have (8.0.50727.163). Any machine using libpq (client or server) or any part of the server will need the correct version of the runtimes to be installed. You can avoid this by building your own libpq.dll using mingw/msys if you like - that will work just fine with a VC++ built server. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com The Oracle-compatible database company
On Mon, Feb 18, 2008 at 04:11:14PM +0100, Hermann Muster wrote: > Dave Page schrieb: > >On Feb 18, 2008 10:05 AM, Hermann Muster <Hermann.Muster@gmx.de> wrote: > > > >>Hi Dave, > >> > >>after testing several combinations I can tell you following, because > >>maybe I couldn't make clear what my problem is. The msvcr80.dll is > >>correctly installed in the > >>C:\WINDOWS\WinSxS\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.762_x-ww_6b128700 > >>respective the > >>C:\WINDOWS\WinSxS\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.163_x-ww_681e29fb > >>folder for my german version of Windows XP. > >> > >>What I don't understand is why the msvcr80.dll is not copied to the > >>PostgreSQL\8.3\bin directory by the PostgreSQL 8.3 setup. > >> > > > >Because it's not supposed to be. > > > > > >>Because when I > >>check the libpq.dll with the Dependancy Viewer, the msvcr80.dll can not > >>be found, however it is installed in the above two folders. And that's > >>where my application comes into play. The libpq.dll can't be used > >>because it does not find the msvcr80.dll. Did you check on that before? > >>Can you load this library? > >> > > > >Yes - if the runtimes are *properly* installed, any application should > >be able to find them in the winsxs folder - thats how Microsoft > >designed it to work. > > > >Did you try doing what I asked in my previous message? > > > > > I finally found the problem. I unfortunately used an "very" old version > of Dependency Walker which couldn't handle the libpq.dll and always > showed that the msvcr80.dll is missing. After installing PostgreSQL 8.3 > and updating the Dependency Walker, everything seems to be fine and my > application can use the libpq.dll. Will test it again in the next days. > > However, one question remains. On my clean Virtual PC Image, there is > already a folder > "C:\WINDOWS\WinSxS\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.163_x-ww_681e29fb" > containing the msvcr80.dll. After installing PostgreSQL or the runtimes, > there is another folder > "C:\WINDOWS\WinSxS\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.762_x-ww_6b128700". The second one is a servicepacked version. IIRC, it also contains some security fixes. > But only the path of the dll installed with the runtimes is recognized. > Does that mean our customers have to install the runtimes at all costs? > That would be the case if our application is running on a client, not the > server PostgreSQL is installed on? Yes, any app linked against libpq need these runtimes. //Magnus
Dave Page wrote: > > You can avoid this by building your own libpq.dll using mingw/msys if > you like - that will work just fine with a VC++ built server. > > Hi Dave, Just some thoughts on the whole libpq.dll thing. It would be really nice from a client distribution view of things to have a libpq.dll that was not so dependency heavy. For the 8.3 release the total amount of files needed to use things such as pg_dump.exe is close to 5mb. maybe a light version of libpq.dll is needed, just the libpq and the open ssl dlls would be ideal, many times all that extra stuff is not needed just to run pg_dump. Didn't there used to be a project on pgfoundry that built the client tools separate from the server build? Just some thoughts, Later, Tony
On Feb 18, 2008 3:38 PM, Tony Caduto <tony_caduto@amsoftwaredesign.com> wrote: > Dave Page wrote: > > > > You can avoid this by building your own libpq.dll using mingw/msys if > > you like - that will work just fine with a VC++ built server. > > > > > > Hi Dave, > Just some thoughts on the whole libpq.dll thing. > > It would be really nice from a client distribution view of things to > have a libpq.dll that was not so dependency heavy. > For the 8.3 release the total amount of files needed to use things such > as pg_dump.exe is close to 5mb. > > maybe a light version of libpq.dll is needed, just the libpq and the > open ssl dlls would be ideal, many times all that extra stuff is not > needed just to run pg_dump. > > Didn't there used to be a project on pgfoundry that built the client > tools separate from the server build? I think so. From our perspective though we need to ensure that libpq will support the same options as the server we ship (for example, I know people that do need Kerberos support) - bundling two different builds will doubtless create confusion. Maybe you should consider reviving that project? -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com The Oracle-compatible database company