<div dir="ltr"><div><div>I agree, building OpenBLAS with mingw-w64 is a snap. The problem is choosing and adapting a mingw based gcc-toolchain and patching the numpy sources according to this toolchain. For the last years I was a happy user of the <a href="http://mingw.org">mingw.org</a> based toolchain. After searching for a 64-bit alternative I stumbled upon mingw-w64 and its derivatives. <br>
<br>I tried out several mingw-w64 based toolchains, i.e. TDM, <a href="http://equation.com">equation.com</a> and more. All mingw-w64 derivatives have there pros and cons. You may know, that you have to choose not only for bitness (32 vs 64 bit) and gcc version, but also for exception handling (sjlj, dwarf, seh) and the way threading is supported (win32 vs. posix threads). Not all of these derivatives describe what they use in a clearly manner. And the TDM toolchain i.e. has introduced some API incompatibilities to standard gcc-toolchains due to its own patches.<br>
<br>A serious problem is gcc linking to runtimes other than msvcrt.dll. Mingw-w64 HAS import libraries fort msvcr80, msvcr90, msvcr100, msvcr110. However correct linkage to say to msvcr90 is more than just adding -lmsvcr90 to the linker command. You have to create a spec file for gcc and adapt it to your need. It is also very important (especially for msvcr90) to link manifest files to the binaries you create. This has to do with the way Microsoft searches for DLLs. "Akruis" (Anselm Kruis, science + computing AG) did the job to iron out these problems concerning mingw-w64 and python. Unfortunately his blog disappears for some time now.<br>
<br>The maintainers of the mingw-w64 toolchains DO NOT focus on the problem with alternative runtime linking. A related problem is that symbols are used by OpenMP and winpthreads you can resolve in msvcrt.dll, but not in msvcr90.dll, so "_ftime"has to be exchanged with "ftime64" if you want to use OpenMP or winpthreads.<br>
<br>In the end my solution was to build my own toolchain. This is time consuming but simple with the help of the set of scripts you can find here: <a href="https://github.com/niXman/mingw-builds/tree/develop">https://github.com/niXman/mingw-builds/tree/develop</a><br>
<br>With this set of scripts and msys2 <a href="http://sourceforge.net/projects/msys2/">http://sourceforge.net/projects/msys2/</a> and my own "_ftime" patch I build a 'statically' mingw-w64 toolchain. Let me say a word about statically build: GCC can be build statically. This means, that all of the C, C++, Gfortran runtime is statically linked to every binary. There is not much bloat as you might expect when the binaries are stripped.<br>
<br>And yes, it is necessary to build an import lib for python. This import lib is specific to the toolchain you are going to use. My idea is to create and add all import libs (py2.6 up to py3.4) to the toolchain and do not use any of the importlibs that might exist in the python/libs/ folder.<br>
<br>My conclusion is: mixing different compiler architectures for building Python extensions on Windows is possible but makes it necessary to build a 'vendor' gcc toolchain. I did not find the time to put my latest binaries on the web or make numpy pull requests the github way due to my workload. Hopefully I find some time next weekend.<br>
<br></div>with best regards<br><br></div>Carl<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">2014-01-30 Sturla Molden <span dir="ltr"><<a href="mailto:sturla.molden@gmail.com" target="_blank">sturla.molden@gmail.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 27/01/14 12:01, Carl Kleffner wrote:<br>
> Did you consider to check the experimental binaries on<br>
> <a href="https://code.google.com/p/mingw-w64-static/" target="_blank">https://code.google.com/p/mingw-w64-static/</a> for Python-2.7? These<br>
> binaries has been build with with a customized mingw-w64 toolchain.<br>
> These builds are fully statically build and are link against the MSVC90<br>
> runtime libraries (gcc runtime is linked statically) and OpenBLAS.<br>
><br>
> Carl<br>
<br>
</div>Building OpenBLAS and LAPACK is very easy. I used TDM-GCC for Win64.<br>
It's just two makefile (not even a configure script). OpenBLAS and<br>
LAPACK are probably the easiest libraries to build there is.<br>
<br>
The main problem for using OpenBLAS with NumPy and SciPy on Windows is<br>
that Python 2.7 from <a href="http://www.python.org" target="_blank">www.python.org</a> does not ship with libpython27.a for<br>
64-bit Python, so we need to maintain our own. Also, GNU compilers are<br>
required to build OpenBLAS. This means we have to build our own<br>
libgfortran as well. The binary is incompatible with the MSVC runtime we<br>
use. I.e. not impossible, but painful.<br>
<br>
<a href="http://mail.scipy.org/pipermail/numpy-discussion/2012-August/063740.html" target="_blank">http://mail.scipy.org/pipermail/numpy-discussion/2012-August/063740.html</a><br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
Sturla<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
<br>
_______________________________________________<br>
NumPy-Discussion mailing list<br>
<a href="mailto:NumPy-Discussion@scipy.org">NumPy-Discussion@scipy.org</a><br>
<a href="http://mail.scipy.org/mailman/listinfo/numpy-discussion" target="_blank">http://mail.scipy.org/mailman/listinfo/numpy-discussion</a><br>
</div></div></blockquote></div><br></div>