Scipy on windows amd64

I spent some more time on this today, and for the first time ever, I managed to build and run the full test suite on windows 64 bits ! The code changes in scipy are small (~50 lines), for internal isnan and co functions in cephes (the windows linker is much stricter about multiple symbols with the same name).

There are still some issues, in particular depending on how I run the test suite, it crashes right away (when nose looks for tests). But when the test suite does run, it successfully pass 3000 unit tests, only fails for a couple (~20 tests), and some of them are relatively harmless. To build both numpy and scipy on windows amd64, I used the following combination:

– gcc : 4.4, snapshot 20090320

– binutils: 2.19.51

– mingw-w64: trunk@rev 692

I use the same versions for the cross compiler (linux->windows) and to build the native compiler from the cross-compiler. Two things need to be done:

– remove redundant pow function from mingwex (it is already available in the MS runtime)

– build the native compiler with -O0. Building with the usual optimization flags build a buggy native compiler (the gcc driver does not call as, resulting in a quite strange “foo.c file type not recognized”, because the driver then gives the foo.c to the linker directly instead of assembling it first).

Maybe scipy 0.7.1 + numpy 1.3.0 will be able to run on windows 64 bits :)

Advertisements

Gfortran + Visual studio

For numpy 1.3, I wanted to make gfortran works with Visual Studio on windows. The reason is two folds: gfortran is the fortran compiler of the gcc 4.* serie ( the 3.* serie starts to become ancient), and g77 will not run windows 64 bits. Making gfortran + gcc work together is of course a no brainer – but linking together fortran code built by gfortran with visual studio is another story.

There are no official binaries for gcc 4.* serie yet on windows – I simply built my own native toolchain from Mac OS X. The makefiles can be found on a mini git branch here:

http://github.com/cournape/cross-mingw-w64/tree/master

Makefile.mingw32 builds the cross compiler from unix (both linux and mac os X work), and makefile.native uses the cross compiler to build the native toolchain. On a fast computer, building both toolchains for C/Fortran/C++ takes little time (< 30 minutes on a quadcore with lots of memory).

Building blas/lapack is easy: just use the make.inc.gfortran in lapack-lite-3.1.1, and run make from cygwin (or msys – if you use cygwin, take care to use the native compilers, and not the cygwin ones). Now, for linking example, we will use the following code snippet:


#include <stdio.h>
void sgemm_(char *, char*, int*, int*, int*,
          float*, float*, int*, float*, int*, float*, float*, int*);
int
main (void)
{
    char transa = 'N', transb = 'N';
    int lda = 2;
    int ldb = 3;
    int n = 2, m = 2, k = 3;
    float alpha = 1.0, beta = 0.0;
 
    float A[] = {1, 4,
                 2, 5,
                 3, 6};
 
    float B[] = {1, 3, 5,
                 2, 4, 6};
    int ldc = 2;
    float C[] = { 0.00, 0.00,
                 0.00, 0.00 };
 
    /* Compute C = A B */
    sgemm_(&transa, &transb, &n, &m, &k,
          &alpha, A, &lda, B, &ldb, &beta, C, &ldc);
 
    printf("C = {%f, %f; %f, %f}\n", C[0], C[2], C[1], C[3]);
    return 0;
}

 

It simply calls into lapack to compute the matrix product between A and B. First, the C code is compiled as follows:

cl /c main.c

Then, copy the following files as follows:

copy libmingw32.a mingw.lib
copy libmingwx.a mingwex.lib
copy libgcc.a gcc.lib
copy libgfortran.a gfortran.lib

(all those libraries are installed either in lib or mingw¥lib directories of the mingw install). Also copy the blas library into blas.lib. You can then link the whole as follows:

link.exe main.obj blas.lib gfortran.lib mingw32.lib gcc.lib mingwex.lib

If everything goes well, the executable main.exe should run, and display the correct matrix product. This works for VS 2008 and should work for 2005 as well. It does not work for me for VS 2003, but this may be a bug in mingw or a problem when building the toolchain.