Re^5: On the road again with Gtk2 and PAR::Packer

Rob, how can you say it proves anything ?

AIUI, Roderick was saying that you were experiencing the failures you're seeing because the perl-generated dlls (such as Pango.dll) are dependent upon various other perl-generated dlls (such as Cairo.dll and Glib.dll).
But you've just shown that an earlier build was fine, even though those same dependencies existed.
So the cause of the problem must be something else.

Perhaps I've misread what he said, or have missed something else, but I'm starting to wonder whether your problem would disappear if you were to change the '.xs.dll' extensions to '.dll'.
I'd first change the existing setting of $Config{dlext} from 'xs.dll' to 'dll' - by making that change in both lib/Config_heavy.pl and lib/Config.pm. (You can run perl -V:dlext to verify that your edits have worked. Note that it would need to report 'dll', not '.dll')
Then I'd rebuild those Gtk2 modules

I find that renaming Strawberry dlls from 'xs.dll' doesn't break anything - at least it didn't for me when I just tried it.
Unfortunately you can't simply do that - because the Pango dll will still be looking for Cairo.xs.dll and Glib.xs.dll. So I think you'd have to rebuild the modules if you want to give that a try.
At least, that's what I would be doing.

Having said that, FAIK it may be possible to get things to work without having to change the extension back to 'dll'.

Cheers,
Rob

Comment on Re^5: On the road again with Gtk2 and PAR::Packer Download Code

Replies are listed 'Best First'.

Re^6: On the road again with Gtk2 and PAR::Packer
by frazap (Monk) on Feb 21, 2019 at 10:37 UTC

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

GLib-GObject-CRITICAL **: g_boxed_type_register_static: assertion `g_type_from_name (name) == 0'

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.

[reply]
[d/l]
[select]


go ahead... be a heretic
	PerlMonks