Welcome to the Monastery | |
PerlMonks |
comment on |
( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
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': 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: 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: 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
|
|