> From: Roderich Schupp > Cairo is not the one referencing symbols from other "glue" DLLs, > AFAICT Pango and Gtk2 are the "culprits". There's probably a reason > why they do this, > but take it to their respective maintainers. But since it > works outside of > a packed executable, my guess is that they have little > inclination to change it. > Esp. since it's PAR::Packer that's to blame here - because > PAR::Packer literally > modifies DynaLoader in order to load DLLs using mangled names.
I am not fully agree here. PAR is well recognized technique, and if you have a fix to CPAN module that allows PAR usage to the said module, the chances to get the module updated are high. > > if - NOT - then the problem could be resolved by adding needed > > DLLs into the PAR executable with "-l" - it does not > renames them, AFAIK. > > No, this has been tried before and doesn't work. To repeat myself: > you end up with two copies of the same DLL and _both_ get loaded. > Then some functions are executed in one copy and some in the other > (or perhaps its global variables). This screws up the glib/gobject > initialization > and leads to immediate program death. fortunately you've found root of a problem, you need to nail down the exact module in a problem. Is it Pango CPAN module? This dual DLL loading - due to some Perl module misinterprets whether XXX.dll already loaded - should be fixed. IOW - how exactly it computed that "Cairo.dll" is already loaded? Regards, Vadim.