• I have duplicated my strawberry perl tree, renamed the original folder to remove it from the window path
• removed (renamed) the Glib, Gtk2, Cairo, Pango folder in site/lib and site/lib/auto
• install the Gtk2 stuff from sizyphusion
• Packed with pp using Shawn auto_link script, and with adding (as proposed by him) on top of my first script

BEGIN {
    if ($ENV{PAR_0}) {
        print "Adding $ENV{PAR_TEMP} to the path";
        use Config;
        $ENV{PATH} = "$ENV{PAR_TEMP}$Config{path_sep}$ENV{PATH}";
    }
};
[download]

the packing works

If the error below was caused by the mangled dll's name problem, I would still have got it in that situation.

With my compile of the Gtk2 stack ( and the .xs.dll), I'm still bitten by

Update 1(some days later)

And I confess, I didn't try Rob's suggestion here

Yes, I did. I have

• installed a second setup with a new perl portable from strawberry (perl 5.20.3)
• changed the dlext in the two files
• renamed all the existing dll in the perl tree to remove the .xs. part (strangely there does not seems to be any cross reference from one dll to another)
• recompiled the Gtk2 stack

In the first perl setup with the gtk2 download from sisyphusion pp_autolink.pl -o simple.exe simple.pl gives a working exe, in the second setup, the exe crash with

Can't load 'C:\Users\..\cache-1551275941\ec21b557.dll' for module Pang
+o: load_file:The specified module could not be found at C:/spp20_2/pe
+rl/lib/DynaLoader.pm line 193.
[download]

Update 2

The working packed exe was made with PAR::Packer 1.012 (version from META.yml) with perl 5.12

I did this

• Unzip the exe using windows zip
• Zip it again to test.zip (maybe I could have just renamed the exe in zip ?)
• With pp from PAR::Packer version 1.037
pp -o test.exe test.zip

Now test.exe fails with Can't locate loadable object for module Glib in @INC (@INC contains: ..)) at C:/strawberry/perl/site/lib/PAR/Heavy.pm line 99.

To go somewhat deeper, I installed a portable version of perl 5.12 and PAR::Packer version 1.012. And the test above works.

So my problems were not resulting from the foo.xs.dll versus foo.dll, but rather of a change it the way PAR::Packer and pp worked.

F