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'
.
.
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
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";
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. | [reply] [d/l] [select] |