http://www.perlmonks.org?node_id=1011833


in reply to Re^15: if Digest::SHA1 loaded Can't load LibXML/LibXML.dll Invalid access to memory location
in thread if Digest::SHA1 loaded Can't load LibXML/LibXML.dll Invalid access to memory location

if you know which dll it is , edit MAKEFILE LDDLFLAGS add -Wl,--image-base=0x70000000 and dmake test again (0x70000000 is default rebase address)

Excellent !! That fixes the problem I have with 32-bit perls and PDL::Graphics::PLplot (when PDL::Graphics::PLplot is built as part of the PDL build).

However, it doesn't help with 64-bit perls.
Could it be that the 0x70000000 needs to be a different value on 64-bit perls ?

Note: With 32-bit perls the dll fails to load, with an error message stating that the dll is not a valid Win32 application.
With 64-bit perls the dll also fails to load, but the error message is a little different, claiming an "Invalid access to memory location". After amending the Makefile as per suggested, PDL::Graphics::PLplot *does* get rebuilt (as expected), but the failure and error message remain unchanged.

Cheers,
Rob
  • Comment on Re^16: if Digest::SHA1 loaded Can't load LibXML/LibXML.dll Invalid access to memory location

Replies are listed 'Best First'.
Re^17: if Digest::SHA1 loaded Can't load LibXML/LibXML.dll Invalid access to memory location
by bulk88 (Priest) on Jan 06, 2013 at 07:18 UTC
    Tried a newer GCC or the other Mingw build (org or w64)?

    Invalid access to memory location usually means DllMain did a segfault and Windows caught that exception, and unloaded the DLL, so the LoadLibrary failed.
[reply]
Re^17: if Digest::SHA1 loaded Can't load LibXML/LibXML.dll Invalid access to memory location
by Anonymous Monk on Jan 06, 2013 at 08:10 UTC

    Could it be that the 0x70000000 needs to be a different value on 64-bit perls ?

    Probably not, but I have read in one of those rebase links that rebas-ing should be done @ install time for least conflicts, so you should get more info, check for ImageBase conflicts for all dll's involved (even those in %WINDIR% )

    Also try depends.exe Ctrl+O perl.exe , F7 ...foo.pl to see a LoadLibrary trace, maybe you'll see something new, but so far it sounds like the same thing I saw

[reply]
      Thanks guys (Anonymous, Bulk88) - you've given me enough links/thoughts to last a lifewtime ;-).
      I'll poke at this a bit more when time permits.

      Luckily I *can* build PDL::IO::Graphics successfully on both 64-bit and 32-bit perls so long as I build it separately from the PDL build. (However, modifying the Makefile's LDDLFLAGS is a simpler fix, where it works.)

      For my 32-bit perls on this Windows 7 (x64) box I use a mingw.org port of gcc-4.7.0. (It built the perls in question, as well as the plplot library.)
      On a (soon-to-be-retired) Windows Vista (x64) box, I used a mingw.org port of gcc-4.5.2. It, too, had built the 32-bit perls and plplot library on that box - and suffered the same problem (and workaround) wrt PDL::Graphics::PLplot.
      However, the problem seems to affect more perls on the Windows 7 box, than were affected on the Vista box. (For example, iirc, perl-5.12.0 is affected by this on Windows 7, but not on Windows Vista.)

      As regards the x64 builds, on both boxes I have used the same mingw64.sf port of gcc-4.7.0 to build the perls and the plplot library. (I think that more x64 perls are affected by this on the Windows 7 box than on the Vista box ... but I would need to check on that in order to be sure.)

      Cheers,
      Rob
[reply]
[reply]

In Section Seekers of Perl Wisdom