> 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.

Reply via email to