<p dir="ltr">On 11 Oct 2014 14:42, "Antoine Pitrou" <<a href="mailto:solipsis@pitrou.net">solipsis@pitrou.net</a>> wrote:<br>
><br>
> On Sat, 11 Oct 2014 00:30:51 +0000 (UTC)<br>
> Sturla Molden <<a href="mailto:sturla.molden@gmail.com">sturla.molden@gmail.com</a>> wrote:<br>
> > Larry Hastings <<a href="mailto:larry@hastings.org">larry@hastings.org</a>> wrote:<br>
> ><br>
> > > CPython doesn't require OpenBLAS.  Not that I am not receptive to the<br>
> > > needs of the numeric community... but, on the other hand, who in the<br>
> > > hell releases a library with Windows support that doesn't work with MSVC?!<br>
> ><br>
> > It uses AT&T assembly syntax instead of Intel assembly syntax.<br>
><br>
> But you can compile OpenBLAS with one compiler and then link it to<br>
> Python using another compiler, right? There is a single C ABI.</p>
<p dir="ltr">In theory, yes, but this is pretty misleading. The theory has been known for years. In practice we've only managed to pull this off for the first time within the last few months, and it requires one specific build of one specific mingw fork with one specific set of build options, and only one person understands the details. Hopefully all those things will continue to be available and there aren't any showstopper bugs we haven't noticed yet...</p>
<p dir="ltr">(Before that we've spent the last 5+ years using a carefully preserved build of an ancient 32 bit mingw and substandard BLAS .dll that were handed down from our ancestors; we've had no capability to produce 64 bit official builds at all. And a large proportion of users have been using 3rd party proprietary builds.)</p>
<p dir="ltr">-n</p>