Hi there,

Roderich, you were saying (2.2012) that a trick that worked to pack Gtk2 based 
script, worked "because of a little known feature of DynaLoader.pm:
When asked to load the "glue" DLL for module Foo::Bar DynaLoader will usually 
look for a file named "auto\Foo\Bar\Bar.dll" below any directory in @INC.
PAR::Packer extends this search to look for this path also in the zip that is 
part of the packed executable. Now you effectively removed these paths from the 
packed executable, so this fails. In a last ditch effort DynaLoader simply 
punts and asks the OS to load "Bar.dll" (i.e. using its usual search strategy, 
on Windows that means looking in the directories in PATH). Every DLL you add to 
the packed executable with "pp -l ..." is flatly packed in the zip in directory 
shlib/ARCH and unconditionally extracted in the cache area. Also the packed 
executable runs with the cache directory prepended to PATH. So when asked to 
load the glue DLL for Gtk2.pm etc, DynaLoader loads Gtk2.dll from the cache 
directory. That way we get rid of the second copy of the DLLs (extracted and 
loaded with mangled names) and inter-DLL symbol references work as expected."

I'm hitting a wall with a recent strawberry perl setup, where all the dlls 
during modules installs are named foo.xs.dll. Would that be a reason why it 
fails, DynaLoader searching   for foo.dll

Could I try to change DynaLoader to also try with xs.dll ?
how ?

Thanks

François


Reply via email to