Sturla Molden <sturla.mol...@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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com