Bug #48576 for Perl-Dist-Strawberry: Ext-lib: XML2/XSLT support

Hi, this is another post with a suggestion of reorganising the external libraries bundled with strawberry. Currently the XML2 support in strawberry seems to based on zlatkovic.com binary of libxml2.dll version 2.6.30 (the latest version is 2.7.3 - but it not the main issue). Libxml2 supports works - so why do I propose a change? *) I have tried to add libxslt support (XML::LibXSLT module) to my strawberry. I downloaded lib[e]xslt.dll from zlakovic.com but did not managed to use it due to some linker problems. These maybe caused by the fact that zlatkovic.com binaries are build with MS compiler and it is not so easy to get it work with mingw - standalone libxml2 works fine; however if you add libxslt the new issues appear - XML::LibXSLT is directly using libxml2.dll and libxslt.dll that then indirectly uses again libxml2.dll (the *.a/*.lib files where probably not well generated therefore mingw linker was slightly confused and ended up with some errros). *) So the only way that works for me was to compile a new libxslt/libexslt from sources. As I have considered strange to have libxml2.dll form zlatkovic.com (build by MS compiler) and lib[e]xslt.dll build myself (mingw) - I have also rebuilt libxml2.dll. *) Then another issues regarding DLL names appear. The biggest one was with libxslt.dll as this external library name (placed in c:\strawberry\bin\libxslt.dll) was in a collision with XML::LibXSLT XS library of the same name (placed in c:\strawberry\perl\site\lib\auto\XML\LibXSLT\LibXSLT.dll) - this simply does not work. The solution was to patch XML::LibXSLT to used a different DLL name - latest SVN trunk version uses LibXSLT.xs.dll. Due to some Dynaloader bug in 5.10.0 (fixed in 5.10.1) it does work with strawberry 5.8.9 but not with 5.10.0. *) So I have decided to change the library name libxslt.dll to libxslt_.dll. And to avoid similar issues I have also renamed libxml2.dll to libxml2_.dll (aka "PATH issue" appears if you have in your PATH before strawberry dirs some other directory containing another copy of DLL with the same name - then this "another" DLL is gonna be loaded and strange thing happens). *) And finaly I also feel that there are some useless files installed with LIBXML2 - so we might wath to tidy-up a little bit e.g. c:\strawberry\c\lib\libxml2_a.lib c:\strawberry\c\lib\libxml2_a_dll.lib So what did I do: - compiled: libxml2-2.7.3 libxslt-1.1.24 with mingw compiler (that one included in strawberry) - used alternative DLL names: libxml2_.dll libxslt_.dll libexslt_.dll - successfully tested with: XML::LibXML (1.69) and XML::LibXSLT (svn trunk) Some comments to the build process: - libxml2-2.7.3 libxslt-1.1.24 have mingw makefiles but a little bit violence on them was necessary to produce what I wanted - both libraries has "strange" approach to static vs. dynamic linkage - by default static lib = libxslt.a; dynamic = libxslt.lib (the same for libxml2, libexslt) - if you want to use static lib (without DLL dependency): gcc example.c -DLIBXSLT_STATIC -lxslt - if you want to use dynamic lib (with DLL dependency): gcc example.c -llibxslt - this approach is very unusual; as no Makefile from CPAN I have seen does not use -DLIBXSLT_STATIC option (that is Win32 specific) I have decided to use just the dynamic linking and put into my strawberry perl just dynamic library - I was in doubts what is the right name because some makefiles uses -lxslt (~libxslt.a) and other -llibxslt (~libxslt.lib). In the end I have decided to use the names: libxml2.a libxslt.a libexslt.a - Directly with gcc it works only with options: -lxml2 -lxslt -lexslt - ExtUtils::MakeMaker handles also: -llibxml2 -llibxslt -llibexslt To test the changes I am proposing try this: 1) remove XML2 support currently installed into strawberry del c:\strawberry\c\bin\libxml2.def del c:\strawberry\c\bin\libxml2.dll del c:\strawberry\c\bin\xmlcatalog.exe del c:\strawberry\c\bin\xmllint.exe del c:\strawberry\c\lib\libxml2.a del c:\strawberry\c\lib\libxml2.lib del c:\strawberry\c\lib\libxml2_a.lib del c:\strawberry\c\lib\libxml2_a_dll.lib del /Q c:\strawberry\c\include\libxml\* rmdir c:\strawberry\c\include\libxml 2) Unzip enclosed ZIPs into c:\strawberry\c libxml2-2.7.3-bin_20090810.zip libxslt-1.1.24-bin_20090810.zip 3) Reinstall existing modules binded to removed LIBXML2.DLL cpan -fi XML::LibXML::Common cpan -fi XML::LibXML (I know that both are distributed together; but this works) All test should pass and both modules should install smoothly. 4) XML::LibXSLT - ver. 1.67 is not Win32-ready yet, we need the latest dev release from svn://axkit.org/XML-LibXSLT/trunk - perl makefile.PL - dmake test - dmake install All test should pass and module should install smoothly. It would be nice if you can consider including XSLT support into the next strawberry release. -- kmx