develooper Front page | perl.par | Postings from October 2006

Re: [ #13508] cannot find Glib.dll on win32, despite beingpackaged in the exe

Thread Previous | Thread Next
Glenn Linderman
October 6, 2006 09:37
Re: [ #13508] cannot find Glib.dll on win32, despite beingpackaged in the exe
Message ID:
On approximately 10/6/2006 2:08 AM, came the following characters from 
the keyboard of Marc Lehmann:
> On Thu, Oct 05, 2006 at 02:50:17AM -0400, Glenn Linderman via RT <> wrote:
>> So here is code to a working work-around for the PAR problem of not 
>> extracting .dll files that refer to each other in a consistent place so 
> Now I understand. Your problem is similar, but ultimately different.
> My problem wasn't that dlls aren't being unpacked, but that they were being
> unpacked under the wrong name.
>    use Glib; # pull in Glib.dll as _another_ name
>    use Gtk2; # pull in Gtk2.dll and Glib.dll, which isn't anywhere
> So the dlls are being loaded and unpacked, but under the wrong name.
> Packaging Glib.dll manually did not work either, as Gtk2 would refer to
> Glib.dll and Glib would refer to the <md5>.dll copy, resulting in crashes.
Well, my understanding is that ImageMagick is kind of like your Gtk2... 
it pulls in the first .dll file, which goes looking for the rest of 
them, and they are nowhere to be found.  The first one is unpacked as a 
temp file, so it cannot be found in the lib\auto\Image\Magick directory 
when looking at the par_cache area after the fact, either.  But looking 
for a file of its size in the par_cache area, one can compare and 
discover that that first .dll does get extracted... but it can't find 
its siblings (which aren't referenced via standard Perl autoload 
techniques) by their proper names in the same directory as the first .dll.

So I guess that is slightly different, but curing the "different name" 
and "different location" problems would seem to help us both.  So I'm 
not at all sure what you have done to cure your problem.  From what you 
said, I thought I was doing what you did up until the need to actually 
extract the .dlls to the right place.
>> CONs:
>> It extracts the modules packaged this way on every run.  Depending on 
> It should be made to use the cache par assumingly provides (I could never
> get the cache to work, so I do not use caching, but in theory that would
> alleviate the speed problems).
If you are referring to the on-disk cache under $ENV{'PAR_TEMP'}, that 
is where I expected the Image::Magick .dlls to be extracted to.  And 
some versions of PAR actually did it, and over time with "fixed" so that 
they didn't anymore.
>> -f check for a particular .dll file (since they are the ones PAR doesn't 
> From what I read, par internally should do this, so when implementing
> such an option it could be taken care of. So the switch would trade a
> (possibly) slower first-time startup with a faster second-time startup.
Well, yes, it does, for files that it actually unpacks, which doesn't 
include the "other" ImageMagick .dll files as far as I can determine... 
there are a bunch of .dll files in the par cache, but not enough of the 
right byte size to be the ImageMagick ones.

Glenn --
A protocol is complete when there is nothing left to remove.
-- Stuart Cheshire, Apple Computer, regarding Zero Configuration Networking

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About