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

Replies are listed 'Best First'.
Re^3: On the road again with Gtk2 and PAR::Packer by syphilis (Archbishop) on Feb 14, 2019 at 08:48 UTC
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	[reply] [d/l]
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


good chemistry is complicated, and a little bit messy -LW
	PerlMonks