On Tue, Feb 14, 2012 at 11:08, Roderich Schupp <roderich.sch...@googlemail.com> wrote: > But maybe this has changed (it was a Windows only > phenomenon, anyway). > As I said, I'll have a look, but don't hold your breath.
I downloaded the latest gtk+-bundle from http://ftp.gnome.org/pub/gnome/binaries/win32 and build the latest Gtk2 and dependencies from CPAN. The problem is still there: for example .../auto/Pango/Pango.dll references symbols from .../auto/Cairo/Cairo.dll and .../auto/Flib/Glib.dll - so executive summary is: it will not work. TL;DR: On Linux (or any ELF-based system) you can get away with this: have unresolved symbols in the DLL, but don't mention the resolving shared library in the NEEDED list. As long as you manage that the resolving library has been loaded _before_ Pango.dll is loaded, then the symbol will be resolved. And Pango.pm does "use Cairo" which causes Cairo.dll to be loaded before its own bootstrap causes Pango.dll to be loaded. On Windows, you can't have unresolved symbols unless you explicitly specify the DLL from which the should be resolved. Hence Pango.dll lists Cairo.dll as a prerequiste DLL. By the same argument as above, Cairo.dll has already been loaded, so it works. However, in a packed executable Cairo.dll has been extracted into the cache area using a mangled name like 406bec98.dll. This has indeed been loaded (because PAR::Packer intercepts Dynaloader's request to load Cairo.dll and extracts it - if necessary - and loads 406bec98.dll instead). Apparently the Windows runtime loader "remembers" the already loaded DLLs using the filename as the key, hence does not know that 406bec98.dll is the same as Cairo.dll The result is a pop-up "Can't find Cairo.dll". BTW, [rt.cpan.org #55390] suggests downgrading Module::ScanDeps and may have a valid point: apparently packing a script that contains "use Gtk2" does _not_ imply packing Cairo.pm and Cairo.dll. I'll fix that up in Module::ScanDeps. But even if I pack using "pp -M Cairo .." (and checking with "unzip -l packed.exe" that the whole dependency tree of Gtk2.pm has been packed), the above problem persists. Cheers, Roderich
