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

GCC created a relocation entry http://source.winehq.org/source/include/winnt.h#L3027 for an relocation type unknown to 32 bit x86 windows. Which is the rogue entry, I don't know since I dont have the DLL, you do. You can try a "dumpbin /relocations" and post the contents, or analyze them yourself.

What would I be looking for? objdump doesn't list any unknown types, without -s its 

    339 ABSOLUTE
  44811 HIGHLOW

[download]
about ~2MB worth of text

With -s its 

    494 ABSOLUTE
  75652 HIGHLOW

[download]

I could send you the dlls (if you know a no-hassle service), but rebasing seems to have fixed it, or was that just coincidence?

  • Comment on Re^13: 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^14: if Digest::SHA1 loaded Can't load LibXML/LibXML.dll Invalid access to memory location
by bulk88 (Priest) on Dec 06, 2012 at 22:20 UTC
    Rebasing it fixed it because it didnt have to be rebased by windows! Its bugs with GCC.
[reply]

      Rebasing it fixed it because it didnt have to be rebased by windows! Its bugs with GCC.

      I kinda doubt that

[reply]
        PE is not a FOSS or POSIX platform. It gets a low priority from GCC's devels. There are bug reports open in their bugzilla on problem with incorrect PE relocation entries.
[reply]
Re^14: if Digest::SHA1 loaded Can't load LibXML/LibXML.dll Invalid access to memory location
by syphilis (Archbishop) on Jan 05, 2013 at 03:15 UTC
    rebasing seems to have fixed it

    Pardon the dumb question ... but how does one do this rebasing ?
    There's a few (native Win32, not Cygwin) dll's that I'd like to try this on, but I don't understand how to go about it. (A step-by-step guide would be handy.)

    Cheers,
    Rob
[reply]
      update: ok, step by step
      • perl Makefile.PL
      • dmake test :) and you notice this error pops up
      • if you know which dll it is , edit MAKEFILE LDDLFLAGS add   -Wl,--image-base=0x70000000 and  dmake test again (0x70000000 is default rebase address)

      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 :)

[reply]
[d/l]
[select]
[reply]
        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]

In Section Seekers of Perl Wisdom