On Tue, Feb 14, 2012 at 11:08, Roderich Schupp wrote:
But maybe this has changed (it was a Windows only
As I said, I'll have a look, but don't hold your breath.
I downloaded the latest gtk+-bundle fromhttp://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
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
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
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.