Koha 3 on Win32 w/Strawberry Perl Notes [Koha Developer Wiki]

- Koha 3 on Win32 w/Strawberry Perl Notes

Koha 3 on Win32 w/Strawberry Perl Notes

General Stuff:

Where things stand:
- Koha 3's Makefile.PL should detect a Win32 platform and adjust its defaults accordingly. (NOTE: As of Koha 3.0 Alpha Makefile.PL is broken on win32.)
- All Perl modules appear to compile/install fine with the exception of the following: (Current installation status follows each.)
  - DBD::mysql Successful
  - YAML::syck Successful (But see notes below.)
  - Text::Iconv Successful
  - Net::Z395::ZOOM Successful
  - MARC::File::XML Successful
  - XML::LibXML Successful
  - XML::Simple Successful
  - XML::SAX::ParserFactory Successful
  - XML::LibXSLT Unsuccessful
  - XML::RSS Successful
  - XML::Dumper Successful
  - Schedule::AT Semi-successful (See notes below.)
- Zebra has been installed, but not configured as it awaits a working install of Koha 3. There may be some issues to be addressed here as well.

Environment:
- Strawberry Perl 5.8.8 is used throughout
- dmake is used throughout

DBD::mysql

STATUS: Successful
- SUCCESS AT LAST! Use the info below BUT link to libmysql.lib rather than to mysqlclient. This bit of intelligence came from MySQL's site here.
- Here is the thread that set me in the right direction: http://lists.mysql.com/perl/3589
- After downloading Randy Kobes' script you need to apply this patch:

--- mysql_config_win32.pl       Thu Jan 24 13:23:47 2008
+++ src/mysql_config_win32.pl   Thu Jan 24 13:40:18 2008
@@ -53,7 +53,7 @@
 my $client_libs = '-lzlib';

 $mysqladmin = Win32::GetShortPathName($mysqladmin);
-my $v = qx($mysqladmin -V);
+my $v = qx($mysqladmin version);
 unless ($v) {
   print STDERR "Problem running $mysqladmin - aborting ...\n";
   exit(1);

You will also have to apply the following patch by Randy to the DBD::mysql Makefile.PL (NOTE: This patch is old and changes will need to be applied manually!!!):

--- Makefile.PL.orig	Sun Jul  3 16:01:18 2005
+++ Makefile.PL	Wed Jul 20 23:32:10 2005
@@ -3,7 +3,7 @@
 BEGIN {
     use Config;

-    if ($] == 5.008 && $ENV{"LANG"} ne "C") {
+    if ($] == 5.008 && $ENV{"LANG"} ne "C" && $^O ne 'MSWin32') {
 	$ENV{LANG} = "C";
 	print STDERR "\n\n\n\$ENV{LANG} is not 'C' execing 'perl Makefile.PL'".
 	" with ENV{LANG} == 'C'\n You can skip this check by: 'export ".
@@ -50,12 +50,13 @@

 my $source = {};

-if ($^O !~ /mswin32/i)
 {
   #Check for mysql_config first
   $source->{'mysql_config'}="guessed";
   if ($opt->{'mysql_config'})
-  {
+  {
+    $opt->{'mysql_config'} = Win32::GetShortPathName($opt->{'mysql_config'})
+        if $^O eq 'MSWin32';
     if (-f $opt->{'mysql_config'})
     {
       $source->{'mysql_config'} = "Users choice";
@@ -396,7 +397,6 @@
                          by default the port number is choosen from the
                          mysqlclient library
   --mysql_config=<path>  Specify <path> for mysql_config script
-                         (Not supported on Win32)
   --nocatchstderr        Supress using the "myld" script that redirects
                          STDERR while running the linker.
   --nofoundrows          Change the behavoiur of \$sth->rows() so that it
@@ -445,7 +445,6 @@
     return;
   }

-  if ($^O !~ /mswin32/i)
   {
     # First try to get options values from mysql_config
     my $command = $opt->{'mysql_config'} . " --$param";

After the makefile has been generated, you will need to edit it and add the libmysql.lib library to the ”# — MakeMaker const_loadlibs” section of the makefile.
Then execute the following:

perl Makefile.PL --testdb=test --testuser=test -–testpass=test

Then run the obligatory 'dmake,' 'dmake test,' 'dmake install' and you have it.

YAML::syck

STATUS: Successful (With some reservations as noted.)
I had to link to libxslt_a.lib rather than libxslt.a to get this module to compile.
These libxslt libraries were obtained from Igor Zlatkovic (see XML::LibXSLT notes below.)
Although this module builds fine using these libraries, here is my reservation: I have yet to get XML::LibXSLT to build based on these same libraries. If it turns out that the libraries have to be compiled locally then it will probably be imperative that all modules depending on these libraries be built linked to the same libraries.
After generating the Makefile, edit it and add libxslt_a.lib to the # — MakeMaker const_loadlibs section of the Makefile.
'dmake,' 'dmake test,' 'dmake install'

Text::Iconv

STATUS: Successful
Edit Makefile.PL and comment out the 'exit' at about line 78.
You should link to libiconv.dll.a rather than libiconv.a when compiling under mingw.
After generating the Makefile, edit it and add libiconv.dll.a to the # — MakeMaker const_loadlibs section of the Makefile.
Be sure to include the full path to libiconv.dll.a; if there are spaces in the pathname use 8.3 names.
'dmake,' 'dmake test,' 'dmake install'

MARC::File::XML

STATUS: Successful
'dmake test' will result in massive failures due to problems in the tests rather than real problems. So go ahead… force it!
'dmake install' and you're done.

Net::Z3950::ZOOM

STATUS: Successful
Downloaded and installed Yaz Ver. 2.1.50 (http://ftp.indexdata.dk/pub/yaz/win32/yaz_2.1.50.exe)
Yaz version is important!!
Modified ZOOM Makefile.PL for use on Win32 (see attached Makefile.PL)
dmake, dmake test, dmake install

XML::LibXML

STATUS: Successful
Follow directions here: http://win32.perl.org/wiki/index.php?title=Vanilla_Perl_and_GnuWin32
Once this module is installed, XML::Simple, and XML::SAX::ParserFactory should install…
Note: I have not had the opportunity to repeat these procedures on a clean Win32 installation and so the previous line may be incorrect.

XML::LibXSLT

STATUS: Unsuccessful
This is the tough one… so here are my notes in the raw: (Compiled from various emails…)
First summary:
- Here is what I have on libxslt so far:
- I have been following the general outline for installing libxml from here:
  - http://win32.perl.org/wiki/index.php?title=Vanilla_Perl_and_GnuWin32
- Installed necessary deps from here:
  - http://www.zlatkovic.com/pub/libxml/
- except got libiconv from here:
  - http://gnuwin32.sourceforge.net/packages/libiconv.htm
- used pexports to generate a definition file from libxslt.dll && libexslt.dll
- things blow pexports up after a bit with libxslt.dll sooo…. (more info on this issue in the second summary…)
- tried compiling libxslt and took missing function names from the error messages and added them to the definition file (libxslt.def)
- Even tried adding mangled function names separately and after this format which I saw somewhere googling:
```
_mangled__foo = foo
```
- regenerated the static library (libxslt.a) based on the modified def
- the only remaining complaints the compiler has are about the mangled functions and those are few.
- also tried compiling using gcc and g++ variously
- tried using make, dmake, mingw32-make, and nmake (MSC) all give the same complaints generally

Second summary:

Attached is what should be a fairly complete definition file for the exportable functions in libxslt.dll. I was able to get the library open using Dependency Walker. I think what is causing pexports to blow up here is the way it handles a delay-load dependency call to two libraries which exist on Vista, but not XP. From what I understand, the delay-load allows Windows apps to look for these libs, but not crash if they are not present. This is a guess at best on my part. Never-the-less, the def file was missing ~15 functions because of the failure of pexports. This still does not resolve the undef reference errors when the linker runs. Taking a look at the static lib (*.a) that results from dlltool with vim (I realize it is binary), it differs from the static built by compiling libxslt under cygwin in a number of ways which one might expect from platform differences. However, one of those ways is the inclusion of ___lib_libxslt_a_iname and I'm not sure where this comes from as the def file does not include it nor does the dll afaict. But this same type of reference occurs in libxml.a which was produced by dlltool and XML::LibXML builds just fine. So it may be something with the C sections of XML::LibXSLT. It also appears we have to avoid the pitfall of libxslt.dll bearing a similar name to libXSLT.dll on Win32's case-insensitive file system. The oft repeated suggestion is to rebuild libxslt.dll as libxslt-win32.dll. More fun…. ;-)

FWIW I also include an email communication with Igor Zlatkovic, maintainer of Win32 builds of libxml and libxslt:

Date: Wed, 09 Jan 2008 01:01:57 +0100
From: Igor Zlatkovic
To: Chris Nighswonger
Subject: Re: libxslt-1.1.22.win32.zip 391294 27.08.2007

On 23/12/07 23:42, Chris Nighswonger wrote:

Hi Igor,
I thought maybe you could help me. When running pexports on
libxslt.dll, pexports crashes near the end of the dll. The resullting
definition file does not contain an entire list of functions from the
dll and therefore converting to a static library is incomplete. I did
not know if there was a problem with the dll or if there is something
else I do not understand going on here.

Kind regards,

Hi Chris,
I don't really know what went wrong. If a program you are using crashed,
then it is certainly an error within that program, since programs should
never crash, no matter what input you give them.
Static linking is an issue, since there are incompatibilities with the
C-runtimes involved. Every compiler version seems to supply its own
runtime incompatible with the others. To counter that, I am playing with
the thought to link exclusively to the OS-supplied runtime which would
mean that there can be no precompiled static libs.

If at all possible, use dynamic linking. If that is not an option, then
build your libraries yourself from the source, it is the safest way.

Ciao,
Igor

Here are some further comments on libxslt from: http://use.perl.org/journal.pl?op=display&uid=5735&start=30
(It appears that libxslt for Strawberry Perl would be most welcome by others as well…)

Sunday November 18, 2007
12:21 AM “Final” set of C libraries for Strawberry Perl[ 13 Comments | #34917 ]
After wrestling with C libraries, I've come up with the final set of C-related CPAN modules I'll be supporting out the box for Strawberry Perl 5.10.0.
The C libraries are zlib, bzlib2, iconv, libxml2 and SQLite (including CPAN::SQLite).
libxslt crashes pexports.

Tuesday November 13, 2007
07:18 PM Building C modules hurts[ 2 Comments | #34892 ]
Slowly working through the various C elements people have requested.
Compress::Zlib, Compress::Bzip2, XML::LibXML(libxml2+zlib+iconv) are all green. Text::Iconv doesn't build properly, but I'm happy to ignore that for now as I don't think anyone actually needs it specifically, they mostly use iconv via XML::LibXML.
LibXSLT is a bust, because pexports crashes trying to extract the .def file. So I'm skipping it for this release. Anyone that wants to look at pexports is welcome to try to get it working for me.

XML::Dumper

STATUS: Successful
- Download and install Expat 2.0.0 for Win32 (Version is important!!) from: http://sourceforge.net/project/showfiles.php?group_id=10127
- Install Expat into the following directory: C:\lib\Expat-2.0.0 (This will save you some pain.)
Follow directions here: http://win32.perl.org/wiki/index.php?title=Vanilla_Perl_and_GnuWin32 adapting them for Expat.
- Note: You will not need to create def files. They may be found under the C:\lib\Expat-2.0.0\Source\lib directory. Just move them to the C:\lib\Expat-2.0.0\Libs directory and run 'dlltool' according to the above mentioned instructions.
- After you have created the static libraries and moved them to the proper mingw directories, grab XML::Parser which XML::Dumper depends on.
- Extract the tarball and run 'perl Makefile.PL,' 'dmake,' 'dmake test,' 'dmake install.'
- Now XML::Dumper should install just fine either through CPAN or manually.

XML::RSS

STATUS: Successful
Depends on XML::Dumper

Schedule::AT

STATUS: Semi-successful
This module can be modified to install on Win32, however, there is no case in the code to utilize Window's Task Scheduler.
Koha 3 can be used w/o this module.
A fix for this will most likely have to come by refactoring code in Koha itself.