Hi Roderich,
it works exactly as you say. Now XML::LibXSLT works with pp!
Thanks a lot!
best
maurice
On Sun, Feb 27, 2011 at 12:16 PM, Roderich Schupp
<roderich.sch...@googlemail.com> wrote:
> On Fri, Feb 25, 2011 at 6:07 PM, Maurice Mengel <mauricemen...@gmail.com>
> wrote:
>> 1) Corrections: XML::LibXSLT does show up in scandeps.pl output
>
> Nevermind, found the problem and fixed it.
>
>> On Fri, Feb 25, 2011 at 3:35 AM, Roderich Schupp
>> <roderich.sch...@googlemail.com> wrote:
>>> Looking at LibXSLT.pm (line ~26):
>>>
>>> # avoid possible shared library name conflict on Win32
>>> # not using this trick on 5.10.0 (suffering from DynaLoader bug)
>>> local $DynaLoader::dl_dlext = "xs.$DynaLoader::dl_dlext" if (($^O eq
>>> 'MSWin32') && ($] ne '5.010000'));
>
> That actually causes the problem. XML::LibXSLT localizes
> $DynaLoader::dl_dlext to
> some non-standard value (would otherwise be the same as
> $Config::Config{dlext}).
> This "tricks" DynaLoader to look for LibXSLT.xs.dll instead of LibXSLT.dll.
>
> (It does that because the Perl module XML::LibXSLT is just a Perl wrapper
> for the C library libxslt. Now that shared library might be installed
> as libxslt.dll.
> Nevermind that on Strawberry it's actually called libxslt1_.dll, just for the
> sake of argument assume it were libxslt.dll. Now by convention (implemented
> by DynaLoader) the Perl "glue" library of an XS module Foo::Bar would be
> called Bar.dll and it would live in .../auto/Foo/Bar/Bar.dll. Because
> Windows isn't case sensitive in the case of LibXSLT that would lead
> to two libraries called libxslt.dll and LibXSLT.dll - the same name when
> case doesn't matter. They would live in different locations, but
> still the Windows shared library loader could get confused.)
>
> OK, back to the problem. PAR::Packer (actually it's PAR) also plays
> tricks on DynLoader. It does that to intercept the loading of shared
> libraries so that they can actually be loaded from a .par archive
> (or a packed executable). It duplicates part of DynaLoader's search
> algorithm, esp. the above naming convention. But it doesn't use
> $DynaLoader::dl_dlext, but $Config::Config{dlext}. So it can't "find"
> LibXSLT.xs.dll (even though it was actually packed in).
>
> The solution is easy: use $DynaLoader::dl_dlext in PAR, too.
>
> Can you confirm that the following fixes you problem
> (order of the steps below is crucial, so that PAR::Packer picks up
> the fixed PAR and then packed executable pick up the fixed PAR::Packer):
>
> (1) unpack a PAR tarball from CPAN and copy the attached file
> over lib/PAR/Heavy.pm
> (2) build and install PAR (perl Makefile.PL ... ?make install)
> (3) rebuild and install PAR::Packer from scratch
> (4) re-pack you script and test
>
> Cheers, Roderich
>
