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