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.

In reply to Re^2: Building Math-GSL-0.07 on Win32 (MinGW compiler) by syphilis
in thread Building Math-GSL-0.07 on Win32 (MinGW compiler) by syphilis

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.