> From: Roderich Schupp
> On Thu, Feb 16, 2012 at 09:18, Konovalov, Vadim wrote:
> > 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.
>
> As the current PAR maintainer I beg to differ: PAR is a gross hack.
I see the way to resolve who is correct here - try it.
Come with a working patch to the CPAN module author and see what
happens next.
I can put my efforts to verbally convince them to apply your patch, given
that your patch improves PAR situation.
> >> This dual DLL loading - due to some Perl module
> misinterprets whether
> > XXX.dll already loaded - should be fixed.
>
> "Perl" doesn't misinterpret anything here.
why do you think so?
Rather, what do you mean by ""Perl" doesn't misinterpret anything here"?
It could be that some module XXX has logic:
if (something_was_already_loaded()) {
# skip this and that
...
}
> Do you understand how DynaLoader and DLL loading on the OS
> level works?
I dealt with DynaLoader several times
I happen update Dynaloader somehow in long past to fix something that
I can not remember right now, yet I proposed some patches to p5p,
which are applied to perl core, but some of them are far from perfect,
unfortunately.
yet, I have my own stripped+modified version of dynaloader in my dark
corner to bootstrap my own Perl+tcl/tk+win32 technique, alternate to PAR.
>
> > IOW - how exactly it computed that "Cairo.dll" is already loaded?
>
> I don't know - it's an educated guess. I'm not too familiar
> with the internals
> how Windows loads DLLs
I have another educated guess: DynaLoader.pm tracks loaded DLLs in
@dl_shared_objects file:
push(@dl_shared_objects, $file); # record files loaded
See if Pango / Gtk2 munges with it.
Vadim.
