On Sat, 11 Oct 2014 00:30:51 + (UTC)
Sturla Molden wrote:
> Larry Hastings wrote:
>
> > CPython doesn't require OpenBLAS. Not that I am not receptive to the
> > needs of the numeric community... but, on the other hand, who in the
> > hell releases a library with Windows support that doesn't
Antoine Pitrou wrote:
> But you can compile OpenBLAS with one compiler and then link it to
> Python using another compiler, right? There is a single C ABI.
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 pro
On Sat, 11 Oct 2014 13:59:52 + (UTC)
Sturla Molden wrote:
> Antoine Pitrou wrote:
>
> > But you can compile OpenBLAS with one compiler and then link it to
> > Python using another compiler, right? There is a single C ABI.
>
> BLAS and LAPACK are actually Fortran, which does not have a singl
Sturla Molden 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.
>
> Ther
Antoine Pitrou wrote:
> It sound like whatever MSVC produces should be the defacto standard
> under Windows.
Yes, and that is what Clang does on Windows. It is not as usable as MinGW
yet, but soon it will be. Clang also suffers fronthe lack of a Fortran
compiler, though.
Sturla
___
Is there some reason the Fortran part can't be separated out into a DLL? That's
the C ABI Antoine was referring to, and most compilers can generate import
libraries from binaries, even if the original compiler produced then in a
different format.
Top-posted from my Windows Phone
___
On 11 Oct 2014 14:42, "Antoine Pitrou" wrote:
>
> On Sat, 11 Oct 2014 00:30:51 + (UTC)
> Sturla Molden wrote:
> > Larry Hastings wrote:
> >
> > > CPython doesn't require OpenBLAS. Not that I am not receptive to the
> > > needs of the numeric community... but, on the other hand, who in the
>
Steve Dower wrote:
> Is there some reason the Fortran part can't be separated out into a DLL?
DLL hell, I assume. Using the Python extension module loader makes it less
of a problem. If we stick with .pyd files where everything is statically
linked we can rely on the Python dev team to make sur
DLLs linked by import library at compile time (ie. not using LoadLibrary calls)
and placed in the same directory as the .pyd should be exempt from DLL hell -
Python already creates an activation context when importing pyds to let them
load their own dependencies. Multiple CRTs are also okay as l
I'm not at all an expert on Fortran ABIs, but I think there are two
distinct issues being conflated here.
The first is that there is no standard way to look at some Fortran source
code and figure out the corresponding C API. When trying to call a Fortran
routine from C, then different Fortran comp
On 11 October 2014 19:32, Nathaniel Smith wrote:
> The bigger problem is that getting a usable DLL at all is a serious
> challenge. Some of the issues we deal with: (a) the classic, stable mingw
> has no 64-bit support, (b) the only portable way to compile fortran (f2c)
> only works for the ancien
On 12 Oct 2014 04:20, "Steve Dower" wrote:
>
> DLLs linked by import library at compile time (ie. not using LoadLibrary
calls) and placed in the same directory as the .pyd should be exempt from
DLL hell - Python already creates an activation context when importing pyds
to let them load their own d
12 matches
Mail list logo
