in reply to Re^14: 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

update: ok, step by step

and I'm pooped :)

See Re^3: if Digest::SHA1 loaded Can't load LibXML/LibXML.dll Invalid access to memory location, Re^11: if Digest::SHA1 loaded Can't load LibXML/LibXML.dll Invalid access to memory location

one way is specify the base by adding   -Wl,--image-base=0x70000000 to LDDLFLAGS , when doing Makefile dance

This works well if you trigger the error during the test suite like I did

Another way (i've not tried) is using msdn rebase

or editbin.exe /REBASE

or http://cygwin.wikia.com/wiki/Rebaseall

If you got mingw.org you can  mingw-get install msys-rebase and you'll need  mingw-get install msys-dash for rebaseall (its a 224 line shell script)

I don't know where to get the sources, rebase -V doesn't say, I guess cygwin someplace I already posted before http://www.tishler.net/jason/software/rebase/

http://gmod.org/wiki/GBrowse_Cygwin_HOWTO#Rebaseall

I guess strawberry / citrusperl ought to package rebase.exe and a rebaseall.pl to go along with it

I don't remember now, but I've either read something about a way to have -enable-auto-image-base keep a database of image bases/ranges, so it issues a non conflicting imagebase/range (a free space)

or I thought about it/or patching MakeMaker (or CBuilder whatever) to do the same (keeping a database of image bases/ranges, and replace -enable-auto-image-base with -Wl,--image-base= ) for pre-vista operating systems

but the issue is kinda rare , I've only encountered it less than 6 times in many years, always on a perl install with ~ 1040 cpan distributions :) but only 200-400 dlls

so I suppose PAR-ed up rebaseall.pl packing rebase.exe ought to suffice, if we FAQ up the issue adequately, so folks know what to do :)

If citrusperl offered more binary packages for download (ala ppm), only one guy would have to rebaseall before releasing :)

  • Comment on Re^15: if Digest::SHA1 loaded Can't load LibXML/LibXML.dll Invalid access to memory location
  • Select or Download Code

Replies are listed 'Best First'.
Re^16: if Digest::SHA1 loaded Can't load LibXML/LibXML.dll Invalid access to memory location
by Anonymous Monk on Jan 05, 2013 at 11:01 UTC
[reply]
Re^16: if Digest::SHA1 loaded Can't load LibXML/LibXML.dll Invalid access to memory location
by syphilis (Archbishop) on Jan 06, 2013 at 05:52 UTC
    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
[reply]
      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]

      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]

In Section Seekers of Perl Wisdom