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 compilers require different sorts of name mangling, different ways of mapping Fortran concepts like "output arguments" onto C concepts like "pointers", etc., so your C code needs to have explicit knowledge of which Fortran compiler is in use. That's what Sturla was referring to with the differences between g77 versus gfortran etc. This is all very annoying, but it isn't a *deep* bad - it can be solved by unilateral action by whatever project wants to link the Fortran library. 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 ancient fortran 77, (c) getting even mingw-w64 to use a msvc-compatible ABI is not trivial (I have no idea why this is the case, but it is), (d) <https://github.com/rust-lang/rust/issues/1768#issuecomment-4007553>mingw-built dlls normally depend on the mingw runtime dlls. Because these aren't shipped globally with Python, they have to be either linked statically or else a separate copy of them has to be placed into every directory that contains any mingw-compiled extension module. All the runtime and ABI issues do mean that it would be much easier to use mingw(-w64) to build extension modules if Python itself were built with mingw(-w64). Obviously this would in turn make it harder to build extensions with MSVC, though, which would be a huge transition. I don't know whether gcc's advantages (support for more modern C, better cross-platform compatibility, better accessibility to non-windows-experts, etc.) would outweigh the transition and other costs. As an intermediate step, there are almost certainly things that could be done to make it easier to use mingw-w64 to build python extensions, e.g. teaching setuptools about how to handle the ABI issues. Maybe it would even be possible to ship the mingw runtimes in some globally available location. -n On 11 Oct 2014 17:07, "Steve Dower" <steve.do...@microsoft.com> wrote: > 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 > ------------------------------ > From: Sturla Molden <sturla.mol...@gmail.com> > Sent: 10/11/2014 7:22 > To: python-dev@python.org > Subject: Re: [Python-Dev] Status of C compilers for Python on Windows > > Antoine Pitrou <solip...@pitrou.net> 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 > > _______________________________________________ > 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/steve.dower%40microsoft.com > > _______________________________________________ > 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/njs%40pobox.com > >
_______________________________________________ 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
