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 4, 2006 23:50
Re: [ #13508] cannot find Glib.dll on win32, despite beingpackaged in the exe
Message ID:
On approximately 10/3/2006 4:58 PM, came the following characters from 
the keyboard of Glenn Linderman:
> On approximately 10/3/2006 2:35 AM, came the following characters from 
> the keyboard of Glenn Linderman:
>> On approximately 9/1/2006 2:53 AM, came the following characters from 
>> the keyboard of Marc Lehmann:
>>> Right, I am the only one who managed to package gtk+ with perl on 
>>> windows
>>> so far, to my knowledge, and I had to work around some other par bugs
>>> (such as adding its own defective entry to @INC _multiple_ times during
>>> program execution) but thats not the actual problem.
>>> The actual problem is and stays that par (version 1.52) does not 
>>> correctly
>>> package perl modules using xs and shared objects.
>>> In case it matters, here is what I do a as workaround:
>>> 1. par keeps  alot of crust in @INC leading to clashes if a user has a
>>> different but incompatible pelr installed:
>>>       @INC = grep ref, @INC; # weed out all paths except pars loader 
>>> refs
>>> 2. I pre-push my own libdir in @INC, both at BEGIN time as well as on 
>>> main
>>> program start, because par pushes its own handler in front of it.
>>> 3. I manually package all Glib and gtk2-module related files into my own
>>> hierarchy. No @INC handler required, no renaming required, simply works.
>> Well, I finally found a few minutes tonight while waiting for 
>> something else, to see if I could get ImageMagick working with PAR in 
>> a similar manner.  I have a couple questions about what you do for #2 
>> and #3.
>> 3. Do you use a -A file that lists all the pieces of GTK for reference 
>> in the pp command?  How do you deal with relative vs absolute path 
>> names, and where/how do you target the location of the extracted 
>> pieces?  Do you move them under your build environment so you can 
>> reference them relative, and let them get unpacked under inc, or maybe 
>> a level lower?
> So I tried this; and it works to some extent, but the .dll files do not 
> get unpacked into the tree I set up under inc.  There must be some 
> overriding logic that prevents .dll files from being unpacked; it is 
> likely the same logic that caused the problem in the first place.  Did 
> you have to add code to unpack all the .dll files, or is there some pp 
> switch I am missing that would override that logic, and unpack my .dll 
> files?

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 
that they can find each other.  So for each module that needs to be 
unpacked, -X the module, and then create a -A list for it.  For 
Image::Magick, that would have the following contents:


pp ... -X Image::Magick -A manual_modules.txt

This could be done for several modules, if necessary.

Corresponding code to put at the top of packaged script.

sub PAR_fakeout
{ if ( $0 =~ m@[.]exe$@ ) # must be PAR, eh?
   { @INC = grep ref, @INC; # throw away everything but PAR
     unshift @INC, $ENV{'PAR_TEMP'} . '\\inc\\lgl';
sub PAR_extract
{ my ( $drive, $path, $zip );
   $zip = PAR::par_handle( $0 );
   $drive = substr( $ENV{'PAR_TEMP'}, 0, 2 );
   $path = substr( $ENV{'PAR_TEMP'}, 2 ) . '\\inc\\lgl';
   # return if -f $drive . $path . '\some.dll';
   $path =~ s@\\@/@g;
   $zip->extractTree( 'lgl', $path, $drive );
{ PAR_fakeout(); # do it at compile time
   PAR_extract(); # also extract .dll files from inside lgl path
PAR_fakeout(); # and also at run time


It works.

It might be a prototype for what a new PAR/pp option could do.


It extracts the modules packaged this way on every run.  Depending on 
their size, this may or may not be an issue.  Clearly one _could_ code a 
-f check for a particular .dll file (since they are the ones PAR doesn't 
extract automatically) and assume that if one is there, they all are. 
Such a check would best be made on the last-to-be-extracted .dll file. 
This would hard code one file name in the above code, a commented form 
of the check is shown in the code.

PAR extracts the non-DLL files, so those wind up getting extracted 
twice.  One could play games enumerating all the various DLL files in 
one directory in the PAR file, and the non-DLL files in another, and 
then when doing the extract of DLLs extract the DLLs into the non-DLL 
directory... but that would exacerbate the next CON.  And it is likely 
that the DLLs dominate the size of such modules anyway, so this CON is 
not nearly as severe as the previous one.

It adds complexity to the build options.  'Twould be better if PAR/pp 
would take an extra option --always_extract_dlls_for Image::Magick that 
would cause them to be extracted along with the other source codes.  Or 
even a switch with global applicability  --always_extract_dlls  that 
would apply to all DLLs, as everything works using this technique, 
unlike the current technique.

>> 2. Does "pre-push" mean "unshift"?  And is the path  $ENV{'PAR_TEMP'} 
>> . '/inc'  ?  Or something way different?
> So I told it to put all the ImageMagick files in "im/" so I 
> unshift @INC, $ENV{'PAR_TEMP'} . '\\inc\\im';
> That seems reasonable to me, but I haven't gotten everything working, 
> either, due to the above problem with .dlls not being extracted, and 
> another problem with another package.

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