GCC as well as the all necessary libraries for a toolchain can be compiled with"-disabled-shared". This is supported by the mingw-builds scripts as an option.All the necessary object code from the GCC runtimes will be statically linkedinto the binaries. As a consequence the binary size will be increased incomparison to the standard toolchains. The advantage is, that there will be nodependency to external GCC runtime libraries, so the deployment of pythonextensions is greatly improved. Using such a toolchain is more reliable thanusing -static-XXX flags. However, exception heavy C++ programs (i.e. QT)should be compiled with shared runtimes to avoid problems with exceptionshandling over DLL boundaries. For building typically Python extensions acustomized static GCC toolchain is the best compromise IMHO.

Latest versions should be at:https://bitbucket.org/carlkl/mingw-w64-for-python/downloads

Seenotes below.

1. patches used:

   numpy.patchscipy.patch

2. 64 bit GCC toolchain:

   amd64/    mingw-w64-toolchain-static_amd64-gcc-4.8.2_vc90_rev-20140131.7z    libpython27.a

   1. numpy-1.8.0 linked against OpenBLAS:

      amd64/numpy-1.8.0/    numpy-1.8.0.win-amd64-py2.7.exe    numpy-1.8.0-cp27-none-win_amd64.whl    numpy_amd64_fcompiler.log    numpy_amd64_build.log    numpy_amd64_test.log    _numpyconfig.h    config.h

   2. scipy-0.13.3 linked against OpenBLAS:

      amd64/scipy-0.13.3/    scipy-0.13.3.win-amd64-py2.7.exe    scipy-0.13.3-cp27-none-win_amd64.whl    scipy_amd64_fcompiler.log    scipy_amd64_build.log    scipy_amd64_build_cont.log    scipy_amd64_test._segfault.log    scipy_amd64_test.log

3. 32 bit GCC toolchain:

   win32/    mingw-w64-toolchain-static_win32-gcc-4.8.2_vc90_rev-20140131.7z    libpython27.a

   1. numpy-1.8.0 linked against OpenBLAS:

      win32/numpy-1.8.0/    numpy-1.8.0.win32-py2.7.exe    numpy-1.8.0-cp27-none-win32.whl    numpy_win32_fcompiler.log    numpy_win32_build.log    numpy_win32_test.log    _numpyconfig.h    config.h

   2. scipy-0.13.3 linked against OpenBLAS:

      win32/scipy-0.13.3/    scipy-0.13.3.win32-py2.7.exe    scipy-0.13.3-cp27-none-win32.whl    scipy_win32_fcompiler.log    scipy_win32_build.log    scipy_win32_build_cont.log    scipy_win32_test.log

Thelibpython27.a import files have been generated with gendef and dlltoolaccording to the recommendations on the mingw-w64 faq site. It is essential tonot use import libraries from anywhere, but create it with the tools in the GCCtoolchain. The GCC toolchains contains correct generated mscvrXX import filesper default.

The openblas DLL must be copied to numpy/core before building numpy. All Blasand Lapack code will be linked dynamically to this DLL. Because of this theoverall distro size gets much smaller compared to numpy-MKL or scipy-MKL. It isnot necessary to add numpy/core to the path! (at least on my machine). To loadlibopenblas.dll to the process space it is only necessary to import numpy -nothing else. libopenblas.dll is linked against the msvcr90.dll, just likepython. The DLL itself is a fat binary containing all optimized kernels for allsupported platforms. DLL, headers and import files have been included into thetoolchain.

1. <mingw>bin and python should be in the PATH. Choose 32 bit or 64 bit architecture.

2. copy libpython27.a to <python>libs check, that <python>libs does notcontain libmsvcr90.a

3. apply numpy.patch

4. copy libopenblas.dll from <mingw>bin to numpycore of course don't ever mix32bit and 64 bit code

5. create a site.cfg in the numpy folder with the absolute path to the mingwimport files/header files. I copied the openblas header files, importlibsinto the GCC toolchain.

6. create a mingw distutils.cfg file

7. test the configuration:

   python setup.py config_fc --verbosepython setup.py build --help-fcompiler

8. build:

   python setup.py build --fcompiler=gnu95

9. make a exe installer:

   python setup.py bdist --format=wininst

10. make a wheel:

    Example for built 32-bit exe installer:

    wininst2wheel numpy-1.8.0.win32-py2.7.exe

11. install:

    wheel install numpy-1.8.0-cp27-none-win32.whl

12. test:

    python -c 'import numpy; numpy.test()'

1. apply scipy.patch

2. Check fortran compiler with:

   python setup.py build --fcompiler=gnu95

   and a second time:

   python setup.py build --fcompiler=gnu95

3. Build exe installer:

   python setup.py bdist --format=wininst

4. install

5. test with:

   import scipy; scipy.test()

• two dedicated GCC toolchains for both 32bit (POSIX threads, Dwarf exceptions)and 64 bit (POSIX threads, SEH exceptions)
• statically build toolchain based on gcc-4.8.2 and mingw-w64 v 3.1.0
• languages: C, C++, gfortran, LTO
• customized 'specs' file for MSVCR90 linkage and manifest support (MSVCR100 linkage coming soon)
• additional ftime64 patch to allow winpthreads and OpenMP to work with MSVCR90 linkage
• openblas-2.9rc1 with windows thread support (OpenMP disabled) included

1. DLL deployment: mingw runtime DLLs can not be found at runtime.Solution:use flags for static linking or use a dedicated 'static' GCC toolchain forcompiling and linking. Both solutions should work.
2. Win32 default stack alignment incompatibility: GCC uses 16 bytes sinceGCC4.6, MSVC uses 4 bytes.Solution: use the -mincoming-stack-boundary=2 flagfor compiling. Win64 X86_64 is not affected. This issue is the major causefor segment faults on 32bit systems.
3. Import library problem: numpy distutils does not play well with mingw-w64Solution: create a Pythonlibpython27.a import library with themingw-w64 tools. Use a patched numpy distutils (seenumpy.patch above).
4. Linking against the correct msvcrXXX Version.Solution: create a 'specs'file (howto seehttp://www.mingw.org/wiki/HOWTO_Use_the_GCC_specs_file ) thatincludes necessary informations.
5. manifest resourcesSolution: extend the GCC toolchain with the Manifestresource files and ensure linkage with the help of the 'specs' file.
6. Blas Lapack for numpy scipy There is no silver bullet! A trade-off betweenlicence acceptance, performance and stability remains to be found. OpenBLASon Win32 seems to be quite stable. Some OpenBLAS issues on Win64 can beadressed with a single threaded version of that library.