Differences between revisions 1 and 5 (spanning 4 versions)
Revision 1 as of 2008-04-16 23:38:41
Size: 1341
Comment: copy of the "proposed toolchain" section from the windows page
Revision 5 as of 2008-11-14 13:42:11
Size: 2381
Editor: localhost
Comment: 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]].

== Available Toolchains on Windows ==
Line 7: Line 11:
  * Cygwin: was used until 2.5.x, was dropped due to many issues and libSingular not working properly. M. Abshoff has been working on getting 2.10.x to compile on Cygwin again and is moving fixes back into the main repo.
  * MinGW: problems with Python, has gcc (good), needed POSIX code ported to Windows API. Due to the problems with Python this toolchain is out.
  *
MSVC: 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
=== Cygwin ===
* 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.

===
MinGW ===
 * 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.
}}}

===
MSVC ===
 *
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.

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:

Cygwin

  • 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.

MinGW

  • 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.

MSVC

  • 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.

windows/toolchain (last edited 2008-11-14 13:42:11 by localhost)