[Numpy-discussion] Compiling for free on Windows32
Fri Apr 17 03:50:06 CDT 2009
Sturla Molden wrote:
> On 4/15/2009 6:44 PM, Matthieu Brucher wrote:
>> There is a Python limitation for the compiler.
> There is a common misunderstanding that only VS2003 can be used to
> compile extension objects for Python 2.5. Don't believe it. There is no
> Python limitation for the compiler.
I think Matthieu meant you have to use VS2003 as a MS compiler. Mingw is
obviously fine, since that's how numpy binaries are built for quite a
long time (every single installer I built myself was built with mingw,
and it was already the case before).
It is somewhat a python limitation, in the sense that things can be done
such as to limit the problems. That's exactly what has happened for
py3k, where most IO-related code does not use the C runtime anymore, but
the 'native' low-level, unbuffered system API (read/write and co on
unix, equivalent on windows). You can see more details here:
http://www.artima.com/weblogs/viewpost.jsp?thread=208549 or better if
you have time on this video
http://video.google.com/videoplay?docid=-6459339159268485356. It also
means that python does not rely on the hopelessly broken implementation
of the C library on windows anymore. Maybe things will be better on the
whole C runtime business once we pull off numpy for py3k.
> If you don't share any crt resources with Python, there is no limitation
> on the crt either. If you do a malloc and a corresponding free in C, it
> does not matter what crt you use.
If both happen in the same dll, then yes, malloc/free are ok. But it
will obviously break otherwise - that problem is certainly not specific
to windows, though. For file handles, it happens that almost every unix
implementation of open returns the same number as used internally by the
kernel, so they are trivially 'shareable' between libraries. That's not
true on windows; on windows, win32 handles, as returned from CreateFile
and the likes are shareable, but file id as returned by C open and the
likes are not. So you have to use the win32 specific API to avoid this
> The gfortran team has
> made a binary installer for version 4.4 available in their Wiki.
gfortran 4.4 is pre-released software, though, so take care. I know for
sure that gfortran + MS compiler can mix on 32 bits (at least with VS
2005/VS2008 - There are some mingw bugs for VS 2003, which I have a
workaround for, but it needs some more distutils fu to work correctly so
it is not in the trunk yet).
More information about the Numpy-discussion