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 issue. > 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). David _______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
