[Python-Dev] Status of C compilers for Python on Windows

[Sturla Molden]

Sturla Molden <sturla.molden at gmail.com> wrote:

> BLAS and LAPACK are actually Fortran, which does not have a single C ABI.
> The ABI depends on the Fortran compiler. g77 and gfortran will produce
> different C ABIs. This is a consistent source of PITA  in any scientific
> programming that combines C and Fortran.
> 
> There is cblas though, which is a C API, but it does not include LAPACK.
> 
> Another thing is that libraries are different. MSVC wants a .lib file, but
> MinGW produces .a files like GCC does on Linux. Perhaps you can generate a
> .lib file from a .a file, but I have never tried.

And not to mention that the Fortran run-time depends on the C runtime...
What Carl Keffner did for SciPy was to use a static libgfortran, which is
not liked against any specific CRT, so it could be linked with msvcr90.dll
when the Python extension is built. The vanilla libgfortran.dll from MinGW
is linked with msvcrt.dll. However, not linking with msvcrt.dll broke the
pthreads library, which in turn broke OpenMP, so he had to patch the
pthreads library for this... This just shows some of the difficulties of
trying to combine the GNU and Microsoft compilers. There are many others,
like different stack alignment, differenr exception handling, and the mingw
runtime (which causes segfaults when linked dynamically to MSVC
executables). It's not just getting the CRT right.

Sturla