[SciPy-Dev] Compiling/packaging SciPy on Windows with Visual Studio compilers

Sturla Molden sturla.molden at gmail.com
Thu Jun 4 08:37:31 EDT 2015


On 03/06/15 21:20, Marcus D. Hanwell wrote:

>> You will need a Fortran compiler which is actually compatible with the
>> Visual Studio linker. With gfortran you need to use gcc as linker.
>
> Thanks for the tips, I was hoping to adapt the work we did here to
> make things a little smoother,
> http://www.kitware.com/blog/home/post/231,

MSVC does not know what to do with an object file from gfortran, nor 
what to do with libgfortran.a or mingw32.a.

You can use a DLL created with gfortran in MSVC, either by creating a 
.lib import library for the DLL or by using LoadLibrary from the Win32 
API. This is what you e.g. would do to use OpenBLAS from MSVC.

But this is NOT what you need to build an f2py extension module for 
Python. It contains C and Fortran code, and it must be linked together 
into a single .pyd file. Therefore you must have linker that understands 
object files from gfortran AND the C compiler, and only gcc (MinGW) can 
do that.



 > I don't have access to the
 > commercial Fortran compilers, but it is great to hear what approaches
 > have been tried.

This makes it very simple. Without access to a commercial Fortran 
compiler you cannot build SciPy with Visual Studio given the current 
build utils.



So then you have three options:

1. Do what most people do and build SciPy with MinGW. Beware of all the 
gotchas, including different stack alignment on 32-bit systems. Carl 
Kleffner's toolchain takes care of this.

or

2. Convince your employer (Kitware?) to get you a license for Intel 
Fortran. It will be cheaper than wasting you salary on this. It will 
also give you redistribution rights for MKL (at least last time I 
checked), which solves your BLAS problem.

or

3. Rewrite all of NumPy and SciPy build tools (including f2py) so that 
Fortran code is always compiled separately as DLLs on Windows and 
installed in an appropriate location. That will be a daunting task.



Sturla




More information about the SciPy-Dev mailing list