On Fri, Feb 10, 2012 at 15:11, RAPPAZ Francois <francois.rap...@unifr.ch> wrote: > pp -l "C:\strawberry\perl\site\lib\auto\Cairo\Cairo.dll" -l > "C:\strawberry\perl\site\lib\auto\Pango\Pango.dll" -l > "C:\strawberry\perl\site\lib\auto\Glib\Glib.dll" -l > "C:\strawberry\perl\site\lib\auto\Gtk2\Gtk2.dll" -o invtot.exe invtot.pl > > when I run the exe I got > GLib-GObject-CRITICAL **: g_boxed_type_register_static: assertion > `g_type_from_name (name) == 0' failed at C:/strawberry/perl/lib/DynaLoader.pm > line 223. > cannot register alias Gtk2::Pango::Attribute for the unregistered type (null) > at C:/strawberry/perl/lib/DynaLoader.pm line 223. > Compilation failed in require at script/invtot.pl line 9.
Known problem: [rt.cpan.org #55390] Cannot package with GTK on Windows Note: ignore anything beyond the original bug report, because it fails to address the real problem. AFAIK this is what happens: (1) The -l options for pp aren't necessary: the DLLs should already be present in the packed executable. Please pack without -l and run "unzip -l invtot.exe" to verify. (2) The real problem is that these "glue" DLLs reference each other. This can't work, as PAR::Packer extracts these DLLs using a mangled name. It overrides Dynaloader, so that loading these DLLs *from perl* (e.g. "use Glib;" -> Glib::bootstrap) works, but not on the Windows level. I think that's the reason for error "Compilation failed in require at Gtk2.pm line 31" in #55390. If you add the above -l options then your packed executable contains a second copy of these DLLs in a directory that is extracted without mangling. Now runtime loading succeeds, but apparently the Glib etc initialization code isn't run (or is run in the other copy of the DLL? is that even possible on Windows?). That results in "GLib-GObject-CRITICAL **: g_boxed_type_register_static: assertion `g_type_from_name (name) == 0". BTW, where did you get the Gtk stuff from? Cheers, Roderich
