Re^2: DBD::Pg on Windows with ActivePerl

These are great suggestions. Clearly I am a fish out of water in a Windows world...although I am trying my best to remain enthusiastic and improve upon my shortcomings.

I looked in Event Viewer (once a well-worded Google search told me what Event Viewer was), and there is nothing logged when this error comes up.

I downloaded and ran Dependency Walker (another Google search) and put the in-question modules through their paces. The only thing that comes up RED are two DLLs in c:\Windows\System32...namely SHLWAPI.DLL and IEFRAME.DLL...two DLLs that, before today I never knew existed. And they DO exist in that system32 folder. The parent DLL that tries to call several functions in IEFRAME.DLL is SHDOCVW.DLL (which exists). I can't for the life of me figure out who/what is trying to call something in SHLWAPI.DLL.

I do appreciate the input and the crash course in Windows/MSVC troubleshooting.

Comment on Re^2: DBD::Pg on Windows with ActivePerl

Replies are listed 'Best First'.
Re^3: DBD::Pg on Windows with ActivePerl by tswall (Monk) on Oct 20, 2009 at 20:57 UTC
One other point I just noticed in the Dependency Walker traverse of Pg.dll. I would assume that this library has to link to libpq.dll or some other postgres library, especially as the Pg.dll isn't that large of a file (almost as small as libpq.dll in fact). But yet Dependency Walker doesn't seem to think that Pg.dll depends on any Postgresql libraries. This confuses me. I don't entirely understand how ActivePerl and PPM deal with dependencies, but I would have thought that a traverse of Pg.dll's dependencies would have turned up something in Postgresql's libraries.	[reply]
Re^4: DBD::Pg on Windows with ActivePerl by bulk88 (Priest) on May 09, 2013 at 01:14 UTC
Static analysis with Dependency Walker is sometimes useless. You have to run the process with Dependency Walker. Open perl.exe in Dependency Walker, then click on the "Profile" menu bar item, then click "Start Profiling". Dep Walker will run the perl process, and you will have a log of all manifest activity, static and dynamic (LoadLibrary) DLL loads or misses. `R6034 An application has made an attempt to load the C runtime library incor +rectly. Please contact the application's support team for more information` [download] means there was no manifest on the (XS or database) DLL that tried to load msvcr80.dll. The error comes from MS's code in DllMain that is static linked into every VS 2005 DLL as part of the C library. I gather that the problem is some incompatability between the MSVC runtime libraries that Perl.exe expects and what it finds, as there are a number of posts about sticking MSCVR80.dll or perl.exe.manifest files in the perl/bin directory to make the interpreter happy. I have tried many iterations of this, and I am convinced that I have compatible versions of MSVCR80.dll and a manifest describing it that Perl.exe can find, but I still get this same set of errors. Unlike in the old days with SxS you can NEVER stick a SxSed DLL in PATH and expect it to work (there is local redirection but I've never been able to make it work). It has to be in C:\WINDOWS\WinSxS under one of those crypto hashed folders.	[reply] [d/l]
Re^4: DBD::Pg on Windows with ActivePerl by Anonymous Monk on Oct 21, 2009 at 01:43 UTC
but I would have thought that a traverse of Pg.dll's dependencies would have turned up something in Postgresql's libraries. Maybe DBD::Pg is linked to a static version of Postgresql ... but I think the binaries on http://pgfoundry.org/projects/dbdpgppm/ are broken (depend on vista or .NET or something.)	[reply]