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

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

Thread Previous | Thread Next
Marc Lehmann
October 6, 2006 04:36
Re: [ #13508] cannot find Glib.dll on win32, despite being packaged in the exe
Message ID:
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.

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

> -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.

                The choice of a
      -----==-     _GNU_
      ----==-- _       generation     Marc Lehmann
      ---==---(_)__  __ ____  __
      --==---/ / _ \/ // /\ \/ /
      -=====/_/_//_/\_,_/ /_/\_\      XX11-RIPE

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