pkg-config is a tool used to retrieve meta information about installed libraries, such as compiler options that were used to build the library.

Presumably you don't have the program installed :) — so you might want to consider building it (or try to find a precompiled version) before continuing with the rest of the build process of Math::GSL.  It's supposed to work on Windows, too.

pkg-config looks for .pc files (simple text files, which hold the desired meta info) in certain directories, e.g. as specified in the environment variable PKG_CONFIG_PATH (typically something like /usr/lib/pkgconfig and/or /usr/local/lib/pkgconfig (on Unix)). In your particular case, a gsl.pc file should have been created (from a template named gsl.pc.in) during the build process of the GSL library. You might want to check whether you do have it, before wasting any time on installing the pkg-config tool...   Good luck!

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.

Most likely, it tries to run a pkg-config program, which seems to be a program/library stemming from the http://freedesktop.org initiative. Most likely this means that the install process will not work anywhere other than Linux.

Your best approach would be to rip out/make conditional the ->find('gsl') part and populate %gsl_pkgcfg manually.

How did you manage that part?

I don't understand why strawberryperl doesn't included MSYS.

I don't understand why strawberryperl doesn't included MSYS

I've suggested to adamk that Strawberry *should* include MSYS. I think his reason for rejecting that suggestion was simply to keep the size and complexity of Strawberry down - and I respect his right to do that.
After all, it's not all that hard to install MSYS separately, and then use Strawberry's MinGW compiler inside that shell. (I can probably provide some help with that, if needed.)

Once you've got MSYS and MinGW set up, building gsl-1.11 is straightforward. Just run './configure --disable-shared --enable-static' (assuming you want a static build), followed by 'make check' and 'make install'. IIRC, the 'monte' tests in 'make check' fail - but all other tests pass. There may now be a more recent version of GSL but, if so, I haven't tried it yet.

Cheers,
Rob

Did you install MSYS over strawberryperl? It doesn't look like it from your lib/inc problems.
It may not be all that hard, but its easy to include it, or add an option to download it after install, or simply tell the user what to get where.