seems that there is another Perl installation on the system

it all depends how you "installed" the Strawberry. Because you used the PDL, which only comes in the portable/zip version, if you want to be using that version, you need to run its portableshell.bat to set up the environment correctly.

you can use the cmd.exe where perl command to find every instance of perl in your path; the first it lists is the first it runs across (and thus the one that will be executed). Without running portableshell.bat, I am assuming you will see that older v5.12.3 path, wherever that is, as the only result. While running portableshell.bat, I would hope you would see the Strawberry PDL v5.30.1 as the first perl.exe in the path (and maybe see the older v5.12.3 second). To install a module in the PDL edition, you would need to be inside the portableshell.bat when running cpanm Algorithm::SVM or any other perl-related commands.

You might also want to look into whether you really need the old v5.12.3 -- it depends on how/where it was installed, and whether it was another app that installed it, or just a previous standalone installation of perl. If you really do need multiple instances of perl available on Windows, and it's not caused by some other app installing a perl interpreter for its own needs (which then normally shouldn't have been put in your path), I highly recommend grabbing a copy of berrybrew, which helps manage multiple perls on the same system; the newest version that stevieb has released even allows switching between the default strawberry perls that berrybrew has already handled and "foreign" perls that you have installed elsewhere (either before or after installing berrybrew -- where "foreign" could be non-berrybrew-installed strawberries, or other perl distributions), though I haven't tried that feature yet.

I can confirm that this isn't due to having multiple Perl instances on the system. I can also confirm it isn't related to just the PDL versions of Strawberry.

The Testers matrix shows nothing but failure on Windows platforms, and I've tried numerous things to get it to work (adding #include <cstring> and using namespace std;, removing all instances of Perl and installing just one, trying Perl versions that aren't listed in the failures etc) to no avail.

So there's something else weird going on that I couldn't figure out with the time I had to troubleshoot.

I came back to this, and found that if I perform the following actions, things *seem* to work out ok after I manually download, unpack and cd into the distribution directory:

perl Makefile.PL.solaris
gmake
gmake test
gmake install
[download]

Here is the standard Makefile.PL, that would be used by default when installing with cpanm:

use ExtUtils::MakeMaker;
 
$CC = 'g++';
 
%args = ('CCFLAGS' => '-Wall');
 
if($^O eq 'cygwin') {
  $args{'LDDLFLAGS'} = '-shared -L/usr/local/lib';
}
 
WriteMakefile('NAME'          => 'Algorithm::SVM',
              'VERSION_FROM'  => 'lib/Algorithm/SVM.pm',
              'PREREQ_PM'     => {},
              ($] >= 5.005 ?
               (ABSTRACT_FROM => 'lib/Algorithm/SVM.pm',
                AUTHOR        => 'Matthew Laird <matt@brinkman.mbb.sfu
+.ca>') : ()),
              'OPTIMIZE'      => '-O3',  # segfaults with gcc 2.96 if 
+lower (?)
              'LIBS'          => '-lm',
              'CC'            => $CC,
              'LD'            => '$(CC)',
              'OBJECT'        => 'SVM.o libsvm.o bindings.o',
              'XSOPT'         => '-C++ -noprototypes',
              %args);
[download]

...and here's the Makefile.PL.solaris file I used:

use ExtUtils::MakeMaker;
 
$CC = 'g++';
 
%args = ();
 
if($^O eq 'cygwin') {
  $args{'LDDLFLAGS'} = '-shared -L/usr/local/lib';
}
 
WriteMakefile('NAME'          => 'Algorithm::SVM',
              'VERSION_FROM'  => 'lib/Algorithm/SVM.pm',
              'PREREQ_PM'     => {},
              ($] >= 5.005 ?
               (ABSTRACT_FROM => 'lib/Algorithm/SVM.pm',
                AUTHOR        => 'Matthew Laird <matt@brinkman.mbb.sfu
+.ca>') : ()),
              'OPTIMIZE'      => '-O3',  # segfaults with gcc 2.96 if 
+lower (?)
              'LIBS'          => '-lm',
              'CC'            => $CC,
              'LD'            => '$(CC)',
              'CCCDLFLAGS'    => '-fPIC',
              'LDDLFLAGS'     => '-shared',
              'LIB_EXT'       => '.so',
              'OBJECT'        => 'SVM.o libsvm.o bindings.o',
              'XSOPT'         => '-C++',
              %args);
[download]

The only real difference I see, is that the "solaris" version of the file tells the system to create a shared library, where the default one does not.

The problem/resolution can reliably be reproduced by switching the build to use each of the differing makefiles.

One more note... I had to add #include <cstring> near the top of the bindings.cpp file to rid myself of undefined memcpy errors before the above worked properly.

I followed your advice and it worked! Actually at first I removed older Perl installation but the error remained. Only usage of "solaris" version of makefile helped to solve a problem. Thank you, stevieb!

I will summarise your situation so other people can use this simple hint in order to compile Algorithm::SVM. The error is that (C++'s) memcpy() is not found (during compilation) because of not including the right header in file bindings.cpp. The solution is to insert a #include <cstring> at the includes section of file bindings.cpp of said module. This was enough to install Algorithm::SVM in my Linux box. And I have also sent an bug-mail to the author. So that will bring Algorithm::SVM back to the living.

In your case you have another problem with the linker, because of a mix-up of perl binaries and libraries. The perl executable you are using to build the module (perl Makefile.PL) is v5.12.3. But it's likely that you unzipped the new perl and its libraries to a folder which is searched first by the linker. And it finds first the libraries of the new Perl. If that's the case, you are in for lots more problems...

I do not know what is the practice of having two perls in Windows. Or how does the linker work and how to check its search paths. I am sure some other fellow Monk will be able to advice you with that.

In the meantime, perhaps using the newer Perl (by using its full path e.g. c:/sw/pdl/perl.exe) when you prepare the Makefile will work for you.

bw, bliako