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

I did renamed the folders to avoid the problem of mangled dll names made by PAR::Packer that resulted (?) in the error

So that's the same error as you're now getting - but last time you were able to work around it, and this time you can't.
Have I got that right ?

From your original post:

objdump -x 778ce824.xs.dll | grep "DLL Name" gives
        DLL Name: libcairo-2.dll
        DLL Name: libglib-2.0-0.dll
        DLL Name: libgobject-2.0-0.dll
        DLL Name: libpango-1.0-0.dll
        DLL Name: libpangocairo-1.0-0.dll
        DLL Name: msvcrt.dll
        DLL Name: Cairo.xs.dll
        DLL Name: Glib.xs.dll
        DLL Name: KERNEL32.dll
        DLL Name: perl524.dll
[download]

That's the Pango.xs.dll by a different name - and you can see that it cross-references the Cairo and Glib xs.dlls.
That's the cross-referencing that Roderick said was the cause of the issue (in https://www.mail-archive.com/par@perl.org/msg05011.html).

If you take the Pango.dll from the older package (ie the one that worked) and "objdump -x" it in the same way, does it also report a dependency on "Cairo.dll" and "Glib.dll" (or "Cairo.xs.dll" and "Glib.xs.dll", as the case may be ) ?
If so, then that pretty much proves that the cross-referencing is not the issue.
Else it supports Roderick's view.

Cheers,
Rob

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

Replies are listed 'Best First'.
Re^4: On the road again with Gtk2 and PAR::Packer by frazap (Monk) on Feb 14, 2019 at 10:05 UTC
So that's the same error as you're now getting - but last time you were able to work around it, and this time you can't. Yes ! `:\docs\perl_dll>objdump -x Pango.dll \| grep "DLL Name" DLL Name: Cairo.dll DLL Name: KERNEL32.dll DLL Name: libcairo-2.dll DLL Name: libglib-2.0-0.dll DLL Name: libgobject-2.0-0.dll DLL Name: libpango-1.0-0.dll DLL Name: libpangocairo-1.0-0.dll DLL Name: perl512.dll DLL Name: Glib.dll DLL Name: msvcrt.dll` [download] So the dependecies are the same. Rob, how can you say it proves anything ? F	[reply] [d/l]
Re^5: On the road again with Gtk2 and PAR::Packer by syphilis (Archbishop) on Feb 14, 2019 at 14:08 UTC
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	[reply] [d/l]
Re^6: On the road again with Gtk2 and PAR::Packer by frazap (Monk) on Feb 21, 2019 at 10:37 UTC
A little way down the road: 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. F	[reply] [d/l] [select]


Keep It Simple, Stupid
	PerlMonks