> 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.
... which sometimes faces a problem when different shared libraries (.so) have symbols with same name, and this problem is harder to resolve. > 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". This "Cairo.dll" - is it part of Perl CPAN module? if YES - then proper CPAN perl module should be updated to improve its logic (what is it, BTW?) if - NOT - then the problem could be resolved by adding needed DLLs into the PAR executable with "-l" - it does not renames them, AFAIK. (BTW, I haven't PAR-packed Gtk, so please do not count on my opinion) Vadim.
