jey_suresh has asked for the wisdom of the Perl Monks concerning the following question:

Dear Group,

We are running strawberry Perl on Win2K (clean install), because we could not even get libXML working on activeState Perl! You will find the sad story here in Perlmonks (or if you search "LibXML+Perl5.10+Win32")! :-(

We have downloaded latest LibXSLT package from CPAN. This is not pre-installed with Strawberry Perl. Anyway, we had to make some changes as suggested here:

-> http://osdir.com/ml/lang.perl.xml/2004-01/msg00105.html

This is because, we got "entry point not found for procedure xslApplyStyleSheetUser" error dialog box during the "dmake install" phase.

The package+dll installation has gone off OK now. We could verify this using the dependency walker. Now we try running a small script to test if the installations went well (Actually, we ran "dmake test" first). Now we are getting the dreaded "Can't locate loadable module for module XML::LibXSLT" in @INC...." error (See soln. 1 attempt below). We have scoured the Net, and we have done the following remedial measures already;
1. We have modified the @INC to directly look-up the "LibXSLT.xs.dll" that is present in "\site\lib\auto\XML\LibXML\". Still the same error persists.
2. The .dll file was read-only, and we made it read-write.

In any of your experience, have you got this error in LibXSLT installation? If so, what do you recommend?

Please help us in whatever way you can.

Thanks,
Suresh.

P.S: We have contacted the author of the package regarding this as well.

/*--- [EOF] -------------------- [EOF] -------------*/

  • Comment on Can't locate loadable module error for XML::LibXSLT on Strawberry Perl
  • Download Code

Replies are listed 'Best First'.
Re: Can't locate loadable module error for XML::LibXSLT on Strawberry Perl
by jettero (Monsignor) on Jun 12, 2008 at 10:48 UTC

    Personally, I find compiling things under win32 to be a pretty terrible experience. I do it, but I dislike it. Getting libxslt to work doesn't sound like it's any more fun than getting Gtk2 to work. Fortunately, Gtk2 is precompiled by others in most windows Perls now...

    I'd be surprised if nobody worked out the nasty details of libxslt yet. Have you definitely checked all the available repos? see: ppm wiki, PPM::Repositories.

    -Paul

Re: Can't locate loadable module error for XML::LibXSLT on Strawberry Perl
by Anonymous Monk on Jun 12, 2008 at 11:32 UTC
    We have scoured the Net, and we have done the following remedial measures already;
    Thats not it. Your problem is the same as you had before, manage your path, and cut and paste your error messages, don't retype them (there is no xslApplyStyleSheetUser).
      My apologies: the correct procedure is "xslApplyStylesheetUser" and not "xslApplyStyleSheetUser" as I had put in my OP. This thing pops up as an uncopyable dialog box. So, I had to type it. :-(

      My path is:
       C:\strawberry\c\bin;C:\strawberry\perl\bin; %SystemRoot%\system32; %SystemRoot%; %SystemRoot%\System32\Wbem;
      As you can see, there is hardly anything else to cloud the waters.

      The error message we get is as follows:

      > "C:\strawberry\perl\bin\perl5.10.0.exe" part3a.pl .xs.dll Can't locate loadable object for module XML::LibXSLT in @INC (@INC con +tains: C:/strawberry/perl/lib C:/strawberry/perl/site/lib .) at C:/st +rawberry/perl/site/lib/XML/LibXSLT.pm line 43 BEGIN failed--compilation aborted at C:/strawberry/perl/site/lib/XML/L +ibXSLT.pm line 43. Compilation failed in require at RosieStock.pm line 4. BEGIN failed--compilation aborted at RosieStock.pm line 4. Compilation failed in require at part3a.pl line 4. BEGIN failed--compilation aborted at part3a.pl line 4. > Terminated with exit code 2.

      Also, if you look at the link in my OP, the 'wrapper' dll used by XML::LibXSLT is uniquely (re)named -- LibXSLT.xs.dll as compared to the Win32 binaries libxslt.dll and libexslt.dll, that are being used. Your ciritisms are well intentioned and well taken, but we have definitely learnt from our previous mistakes and calibrated accordingly.

      Regards,
      Suresh.

      P.S: Instead of an anonymous post, you could post with your original name?

        My apologies: the correct procedure is "xslApplyStylesheetUser" and not "xslApplyStyleSheetUser" as I had put in my OP.
        Nope, its xsltApplyStylesheetUser.

        This thing pops up as an uncopyable dialog box. So, I had to type it. :-(
        Try using "Event Viewer".

        compared to the Win32 binaries libxslt.dll and libexslt.dll, that are being used.

        The names have changed, but its the same problem. Your LibXSLT.xs.dll is loading some libxslt.dll which does not have xsltApplyStylesheetUser (its the wrong version, wrong library). You say you verified with "dependency walker", so it must be a path issue.

        Your ciritisms are well intentioned and well taken, but we have definitely learnt from our previous mistakes and calibrated accordingly.
        The typos say otherwise :)

Re: Can't locate loadable module error for XML::LibXSLT on Strawberry Perl
by syphilis (Archbishop) on Jun 13, 2008 at 00:29 UTC
    we had to make some changes as suggested here:
    -> http://osdir.com/ml/lang.perl.xml/2004-01/msg00105.html


    That looks to be on the right path - though it's done a little differently to the way PGPLOT does it (where the same issue arises). In PGPLOT, DLEXT => 'xs.dll' is passed to WriteMakefile(). Setting $Config{DLEXT} as per the above webpage looks a little strange to me. But if dmake install for XML::LibXSLT installed a site/lib/auto/XML/LibXSLT/libxslt.dll.xs, then that part of the fix has worked fine.

    The only other thing that needs to be checked is that DynaLoader.pm knows that it needs to load a dynamic library named libxslt.xs.dll (instead of the usual libxslt.dll). In PGPLOT.pm this is achieved with:
    if($^O =~ /mswin32/i) { local $DynaLoader::dl_dlext = 'xs.dll'; bootstrap PGPLOT $VERSION; }
    That's all that should need to be done ... Oh, no ...wait.. I've just remembered that the DynaLoader.pm that ships with 5.10.0 won't allow that fix !! You'll need to grab a patched version of DynaLoader.pm (such as the one that ships with Activeperl builds 1002 and 1003) and replace Strawberry's existing DynaLoader.pm with it. (That's the first thing you should try - it may now be the *only* thing that you need to do.)

    1. We have modified the @INC to directly look-up the "LibXSLT.xs.dll" that is present in "\site\lib\auto\XML\LibXML\". Still the same error persists.
    2. The .dll file was read-only, and we made it read-write.


    Neither of those steps should be necessary.
    Update: And libxslt.xs.dll should *not* be located in site\lib\auto\XML\LibXML. It should be in site\lib\auto\XML\LibXSLT. (I'm hoping that was a typo :-)
    Update 2: DynaLoader.pm will be fixed in 5.10.1. (The problem with the current version was reported a few days before 5.10.0 was released - but they went ahead and released 5.10.0 anyway.)

    Cheers,
    Rob
      Thank you very much for that, Rob!

      I am glad you caught the gist of my posting. Yes, you are right - typos seem to be the order of the day (as far as my posts fo at least ;-) )

      We have done all that you have recommended. We have just replaced the "new"er DynaLoader.pm (1.0802) from an ActivePerl, build 1002 in the strawberry lib directory (re-booted PC for good measure).

      However, it did not solve the problem :-((. We are still (and persistently) getting the  Can't locate the loadable object for module XML::LibXSLT!
      Anything else that needs to be done by me (short of chanting Abracadabra and spinning three times on one foot like Baba-yaga! :-(( )

      Rob, many, many thanks for your considerate help in this matter.
      Victory seems tantalisingly close, but my nose seems to be all bunged up (I know, I know, I am mixing my metaphors)!

      Thanks and regards,
      Suresh.

        Can't locate the loadable object for module XML::LibXSLT

        This simply means that the object (dll/xs.dll) that DynaLoader.pm needs to load can't be found. Assuming that site/lib/auto/XML/LibXSLT contains a file named libxslt.xs.dll (and doesn't contain a file named libxslt.dll), then it seems that DynaLoader.pm is still trying to load libxslt.dll. This would indicate that LibXSLT.pm has not been correctly modified (as per PGPLOT.pm).

        Cheers,
        Rob