Beefy Boxes and Bandwidth Generously Provided by pair Networks
go ahead... be a heretic

Building Math-GSL-0.07 on Win32 (MinGW compiler)

by syphilis (Bishop)
on Aug 01, 2008 at 14:00 UTC ( #701698=perlquestion: print w/replies, xml ) Need Help??

syphilis has asked for the wisdom of the Perl Monks concerning the following question:

By my antiquated standards, if the source to this module was properly written, building this module would be as easy as:
perl Makefile.PL INC="-IC:/_32/msys/1.0/local/include" LIBS="-LC:/_32/ +msys/1.0/local/lib -lgsl" dmake test dmake install
But the days of such simplicity are long gone - and it's probably time for me to adjust to the complexity and frustration of Module::Build and its co-obfuscators. So ... let's start with the output of running 'perl Build.PL':
Checking for GSL..'pkg-config' is not recognized as an internal or ext +ernal command, operable program or batch file. at line 265 *** can not find package gsl *** check that it is properly installed and available in PKG_CONFIG_PA +TH at line 265
Where do I go from there ?
Line 265 of Build.PL is:
my %gsl_pkgcfg = ExtUtils::PkgConfig->find ('gsl');
I have (a static build of) gsl-1.11. The gsl includes are in C:/_32/msys/1.0/local/include/gsl and libgsl.a is in C:/_32/msys/1.0/local/lib.

Any help appreciated. I promise to try to refrain from the use of expletives during the course of this thread, but I can't guarantee that I'll succeed in meeting that objective. Frankly, when I see that perl Build.PL output, it just makes my blood boil.


Replies are listed 'Best First'.
Re: Building Math-GSL-0.07 on Win32 (MinGW compiler)
by almut (Canon) on Aug 01, 2008 at 14:48 UTC

    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 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_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.


      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_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("$ +")); + 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.
Re: Building Math-GSL-0.07 on Win32 (MinGW compiler)
by Corion (Pope) on Aug 01, 2008 at 14:13 UTC

    Most likely, it tries to run a pkg-config program, which seems to be a program/library stemming from the 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.

Re: Building Math-GSL-0.07 on Win32 (MinGW compiler)
by Anonymous Monk on Aug 02, 2008 at 10:54 UTC
    I have (a static build of) gsl-1.11

    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.

        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.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://701698]
Approved by almut
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others pondering the Monastery: (7)
As of 2020-09-21 03:14 GMT
Find Nodes?
    Voting Booth?
    If at first I donít succeed, I Ö

    Results (124 votes). Check out past polls.