add Robert Kern's comment on MinGW build problems with certain python extensions
converted to 1.6 markup
|Deletions are marked like this.||Additions are marked like this.|
|Line 1:||Line 1:|
|This page is part the [:windows:Sage on Windows port].||This page is part the [[windows|Sage on Windows port]].|
This page is part the Sage on Windows port.
Available Toolchains on Windows
The five million lines of code in Sage are quite demanding on the compiler and the code has been written primarily with gcc on POSIX architectures. Hence in many cases we will have to do a port to MSVC or at a minimum to a non-POSIX API. We have three flavors of gcc (Cygwin, MinGW, Microsoft SFU) and the Microsoft/Intel compilers:
- was used until 2.5.x, was dropped due to many issues and libSingular not working properly.
- has gcc (good)
- M. Abshoff has been working on getting 2.10.x to compile on Cygwin again and is moving fixes back into the main repo.
- problems with building Python
- has gcc (good)
- needed POSIX code ported to Windows API.
- Due to the problems with Python this toolchain is out. Robert Kern stated on April 17th, 2008 on the numpy mailing list:
Ah, this problem again. The build of mingw that you are using were written with msvcrt in mind. For the most part they are compatible with msvcr71, but there are a few places where they reference a table that is different between the two runtimes, namely iostream in C++ and ischar() in C. Consequently, there are some extension modules built with mingw which work with msvcrt because they need iostream, some with msvcr71 because they need to pass FILE pointers, and probably some which won't work with either. The core problem won't be fixed until mingw writes their headers for msvcr71. They may have; it looks like they just released some new builds this month. It would be worth checking these out.
- works well with Python, only 64 bit option (MinGW has alpha support)
- C/C++ portability problems (most code hasn't been ported to MSVC)
- most viable long term option. But we need Fortran support which means Intel Fortran. For certain packages The Intel C/C++ compilers produce much better code (ATLAS) or allow to use assembly optimized code (GMP). At least MSVC 2005 has weaknesses regarding the C99 implementation, so we might want to switch to 2008.
Microsoft Services for Unix
- has gcc (3.3 or 3.4, need to check - 3.3 is not enough)
- produces semi-native DLLs, largely untested with the applications we target
- rumored gcc 4.2 based 64 bit capable new version coming.