so you might want to consider building it (or try to find a precompiled version)

Yes ... I remember now that I installed it once before (and since removed it as it didn't do anything useful wrt the particular task at hand).

Anyway, I've installed the binaries again, and set $ENV{PKG_CONFIG_PATH} to the location of gsl.pc .... and have met all of the pre-requisite conditions.

The next neat little trick performed by this distro is that running 'perl Build clean' clobbers the source file BLAS_wrap.c - which has weird consequences when one comes to run 'perl Build' again (namely, complaints that swig is missing). Actually, I expect it would clobber all of the *_wrap.c files except for the fact that I haven't got beyond trying to compile BLAS_wrap.c. I've taken a look at both Build.PL and the Build file it generates, and I can't really see any reason that BLAS_wrap.c should get clobbered.
Does Module::Build simply have a rule that if the object file exists then both it and the .c file get clobbered by 'clean' ?
Am I simply supposed to *not* run 'perl Build clean' ? (In the meantime, I'm just re-extracting the source between each successive attempt.)

Moving on to the first error when running 'perl Build':

gcc -o blib\arch\BLAS.so BLAS_wrap.o -shared -I./lib -I../lib -LC:/_32
+/msys/1.0/local/lib -lgsl -lgslcblas -lm -gsl
BLAS_wrap.o:BLAS_wrap.c:(.text+0xb42): undefined reference to `Perl_ge
+t_context'
BLAS_wrap.o:BLAS_wrap.c:(.text+0xb53): undefined reference to `Perl_mg
+_get'
BLAS_wrap.o:BLAS_wrap.c:(.text+0xb58): undefined reference to `Perl_ge
+t_context'
BLAS_wrap.o:BLAS_wrap.c:(.text+0xb67): undefined reference to `Perl_sv
+_isobject'
.
.
[download]

First thing to notice is that the command attempts to build a dynamic library with a '.so' extension on Win32. I dunno how that's going to be received further down the track ... though there's no reason I know of that specifying a dll with a .so extension should cause the command to fail. But if we want to resolve perl symbols, don't we need to link to either libperl58.a or perl58.dll ?

Anyone know how to fix that command from within Build.PL ? (It's actually the first compilation that's attempted during the build process.)

I'll continue to prod at this, but I don't know how far I'll get - so suggestions/comments/advice on what's happened so far is appreciated.

Thanks Corion, almut.

Cheers,
Rob

Update: I've just built Math-GSL-0.07 on linux, mainly so I could see how it goes about the task. And, bugger me ... it runs (in essence) the exact same command as the one that failed above:

gcc -o blib\arch\BLAS.so BLAS_wrap.o -shared -I./lib -I../lib -L/usr/l
+ocal/lib -lgsl -lgslcblas -lm -gsl
[download]

Except that when that command runs on the linux box, it works fine. There are no "undefined reference" errors in relation to any symbols at all. What gives ?

Update 2: Doh !! I keep forgetting that Linux happily defers dynamic linking until runtime - and therefore sees no need to complain about the absent Perl symbols. But Windows insists on being able to find the symbols at build time.

I'll submit Math-GSL bug reports.

Update 3: Here's a patch to the Math::GSL-0.07 Build.PL that fixes the above problems:

--- Build.PL_orig    Sun Aug  3 18:20:42 2008
+++ Build.PL    Sun Aug  3 18:03:27 2008
@@ -131,13 +131,14 @@
   my ($self, $to, $file_base, $obj_file) = @_;
   my ($cf, $p) = ($self->{config}, $self->{properties}); # For conven
+ience
 
-  my $lib_file = catfile($to, File::Basename::basename("$file_base.so
+"));
+  my $lib_file = catfile($to, File::Basename::basename("$file_base.$C
+onfig{dlext}"));
 
   $self->add_to_cleanup($lib_file);
   my $objects = $p->{objects} || [];
   
   unless ($self->up_to_date([$obj_file, @$objects], $lib_file)) {
     my @linker_flags = $self->split_like_shell($p->{extra_linker_flag
+s});
+    push @linker_flags, $Config{archlib} . '/CORE/' . $Config{libperl
+} if $^O =~ /MSWin32/i;
     my @lddlflags = $self->split_like_shell($cf->{lddlflags}); 
     my @shrp = $self->split_like_shell($cf->{shrpenv});
     my @ld = $self->split_like_shell($cf->{ld}) || "gcc";
[download]

Now I'm facing just 8 unresolved symbols (regarding long doubles) - which might be a bug in the building of the gsl-1.11 library. I'll investigate when I have time. The bug report is here.