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

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

Thread Previous | Thread Next
From:
Glenn Linderman
Date:
October 3, 2006 16:58
Subject:
Re: [rt.cpan.org #13508] cannot find Glib.dll on win32, despite beingpackaged in the exe
Message ID:
4522F921.2080002@NevCal.com
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?
> 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 -- http://nevcal.com/
===========================
A protocol is complete when there is nothing left to remove.
-- Stuart Cheshire, Apple Computer, regarding Zero Configuration Networking


Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About