Differences between revisions 133 and 134
Revision 133 as of 2010-09-02 19:26:00
Size: 21195
Editor: BillHart
Comment:
Revision 134 as of 2010-09-02 19:38:07
Size: 21240
Editor: BillHart
Comment:
Deletions are marked like this. Additions are marked like this.
Line 49: Line 49:
 || [[http://www.algorithm.uni-bayreuth.de/en/research/SYMMETRICA/ | symmetrica]] || N || N || N || 2.0 || no Windows port yet, but macro heavy. [[worrisome.]] ||  || [[http://www.algorithm.uni-bayreuth.de/en/research/SYMMETRICA/ | symmetrica]] || N || N || N || 2.0 || Pure C, probably trivial to port. Doesn't do arithmetic and actually *requires* INT to be 32 bits ||

This page is part of the Sage on Windows port.

Package Analysis

Below you will find a list of packages in Sage as well as remarks on issues that will potentially come up during the Windows port. As we progress we will add detailed problem reports and how we resolved those issues at individual pages.

Build dependencies of Sage (port these first for a minimal Sage on Windows)

  • Website

    Win32

    Win64

    MSVC

    Version

    Comments

    atlas

    Y

    N

    N

    3.8.p11

    Unconvinced it is actually needed over CBLAS/CLAPACK

    blas

    Y

    Y

    Y

    20070724

    MSVC 2008 built also possible.
    See: CLAPLACK for windows

    boost

    Y

    P

    P

    1.40.0

    Building Boost in Visual Studio - required by Polybori

    bzip2

    Y

    P

    P

    1.0.5

    works fine with MSVC (32 bits at least)
    See: Making a Windows DLL - required by python

    cephes

    N

    N

    N

    Last seriously maintained circa 1994, small library, long doubles - only used in the Cygwin port so far (and FreeBSD in future) - supposedly required to provide long doubles on Windows, which C99 would otherwise provide

    cliquer

    N

    N

    N

    XXXX

    Docs say minor changes to source required for non-unix OSs

    cython

    Y

    Y

    Y

    0.9.6.12

    pure python, no portability issue

    eclib

    N

    N

    N

    20080127.p0

    Works fine on Cygwin, but needs a port to MSVC. Port is probably of medium complexity. A merge of fixes upstream is welcome, but maintainer no longer uses Windows. Maintainer = John Cremona = has never used Windows, as far as I know. Porting is reasonable.

    ecm

    Y

    Y

    Y

    6.1.3

    ECM-6.2 has MSVC project by Brian Gladman

    flint

    Y

    P

    N

    1.06.p1

    flint2 is pure ANSI C except for a very small amount of assembly language pulled from longlong.h in GMP (see MPIR)

    fplll

    N

    N

    N

    2.1.6-20071129.p1

    no Windows port, needs some specialized math functions, but should be a relatively easy port. Upstream will likely merge Windows patches worry?

    givaro

    N

    N

    N

    3.3.2

    no port exists, C++ code uses templates and it migt. be a little tricky to get right. Upstream welcomes patches could be hard.

    glpk

    Y

    Y

    Y

    4.32

    MSVC 2010

    gsl

    Y

    Y

    Y

    1.10.p0

    Brian Gladman maintains a native MSVC port, 32 & 64 bit.

    iml

    N

    N

    N

    1.0.3

    no port exists, but it should be pretty straight forward. this won't be hard, since iml is just clean C code, mostly concerned with mat

    lapack

    Y

    P

    Y

    3.2.2

    See: LAPACK for Windows

    lcalc

    N

    N

    N

    1.22

    somewhat crafty C code, ugly hacks in the user interface, but should be portable to MSVC. Builds fine under Cygwin

    libpng

    Y

    P

    Y

    1.4.3

    port exists: libpng Since that port uses MinGW we need to either use MinGW 64 bit or do an MSVC port ourselves. In this case it seems likely that somebody else has done a proper Windows port. We might also be able to uses the system's library, but there might be issues with featurs, i.e. IE's libpng is supposed to be fairly bad. yep, something builtin to windows might be useful.
    See: libpng MSVC project files MSVC test MSVC

    linbox

    N

    N

    N

    1.1.7

    this will be some heavy lifting, mostly due to some heavy templated code. Upstream is willing to merge and help out.
    See : ApCoCoA

    m4ri

    Y

    Y

    Y

    20071224.p1

    MSVC port done by Martin Albrecht and in upstream.

    mpfi

    N

    N

    N

    1.5.0

    depends on mpfr and gmp, pure C library. Port is simple and will probably be merged upstream
    See: Inria-MPFI

    mpfr

    Y

    Y

    Y

    2.3.1

    Pure C, Windows make file support welcome upstream, depends on gmp. MSVC project by Brian Gladman exists and is recommended by upstream

    mpir

    Y

    Y

    Y

    2.1.1

    MPIR-Windows 2.1.1 is built with MSVC 2010

    mpmath

    Y

    Y

    Y

    Pure python = no problem

    ntl

    Y

    P

    Y

    5.5.2

    works fine with MSVC. Some functions like the time functions use old and crappy Win95+ interfaces. That can be easily fixed. The build requires Perl for a tuned build - See: MSVC 6

    numpy

    Y

    Y

    Y

    20080104-1.0.4.p2

    support by enthought, builds out of the box with MSVC + ATLAS

    openssl

    Y

    Y

    Y

    0.9.8o

    required by Python - builds fine with MSVC (32 bits at least)
    MSVC6, 2008

    pari

    Y

    P

    Y

    2.3.3

    Some build support exists in tree, but it is currently broken. Support from the maintainers exists and they are willing to integrate fixes upstream. The main issue is to get the build system play nice for MinGW+MSVC.
    for 64 bit MSVC MSVC6

    polybori

    N

    N

    N

    0.6.5

    no Windows port, could be tricky, but upstream is willing to cooperate. worry??

    pynac

    N

    N

    N

    XXXX

    Created for and by Sage

    python

    Y

    Y

    Y

    3.2

    excellent support for MSVC, 32 & 64 bit mode. yep, very very good support on windows Only MSVC 2008
    Python 2.7 in MSVC 2010

    ratpoints

    N

    N

    N

    2.1.3

    Windows port doesn't exists. Not even windows distribution of any kind. Except through Sage-VMWare

    readline

    P

    P

    P

    6.1

    port exists: http://gnuwin32.sourceforge.net/packages/readline.htm. Since that port uses MinGW we need to either use MinGW 64 bit or do an MSVC port ourselves. Cuil Search
    Readline through Octave MSVC Python Readline

    sage_scripts

    2.10.2.alpha0

    requires POSIX shell - no idea what it does

    setuptools

    Y

    Y

    Y

    XXXX

    may be required by multiple packages

    scons

    Y

    Y

    N

    0.97

    Works fine on Windows, python based. Don't need a 64 bit port.

    singular

    N

    N

    N

    3.1.1

    Cygwin only, but needs even work there to run properly (libSingular) Needs to be ported to MSVC, upstream very willing to help out, but lacks expertise. Various issues like memory managment (omalloc) need to be sovled (malloc fallback), but build system issues and stuff like signals make this a bigger job. I would assume this is one of the two heavy jobs together with pexpect. This is probably quite hard. And interesting. At least singular builds under cygwin, which is a good sign, I guess.

    sqlalchemy

    Y

    Y

    Y

    Almost pure python, hence no problem

    sqlite

    Y

    Y

    P

    3.7.0.1

    pure Windows port exists (see http://www.sqlite.org/download.html), required by Python - builds fine with MSVC (32 bits at least) Sqlite How to Compile
    Compiling SQLite with Visual Studio 2008

    symmetrica

    N

    N

    N

    2.0

    Pure C, probably trivial to port. Doesn't do arithmetic and actually *requires* INT to be 32 bits

    sympy

    Y

    Y

    Y

    0.5.7

    pure python, no portability issues.

    tcl

    Y

    Y

    Y

    XXXX

    Required by Python's IDLE - builds fine with MSVC (32 bits at least)
    Building Tcl with the free VC++ toolkit

    termcap

    Y

    N

    N

    1.3.1

    port exists: http://gnuwin32.sourceforge.net/packages/termcap.htm. Since that port uses MinGW we need to either use MinGW 64 bit or do an MSVC port ourselves - basic posix, capabilities can be provided by ncurse. Clearly a very difficult port.

    tk

    Y

    Y

    Y

    XXXX

    Required by Python's IDLE - builds fine with MSVC (32 bits at least)
    Tcl/Tk build problem

    zlib

    Y

    N

    N

    1.2.3.p3

    port exists: http://gnuwin32.sourceforge.net/packages/zlib.htm Microsoft ships a copy under some name, so we might be able to "just" use the system one.

    znpoly

    N

    N

    N

    0.9

    No port. Not even any windows distribution, but mostly pure C. Small amount of assembly language pulled from longlong.h in GMP (see MPIR)

Other dependencies of Sage (may be omitted for now)

Runtime dependencies of Sage (these are probably only needed at runtime for specific functionality)

  • Website

    Win32

    Win64

    MSVC

    Version

    Comments

    cddlib

    N

    N

    N

    094b.p1

    unclear how hard the port will be, but shouldn't be too hard.

    cu2

    cubex

    cvxopt

    Y

    N

    N

    0.9.p5

    Has Windows build support, provides binary packages

    dikcube

    examples

    2.10.2.alpha0

    no compiled code, i.e. no problem

    extcode

    XXX

    various code in interpreted languages, i.e. javascript, java, Magma, pari, singular, no porting issues

    flintqs

    20070817.p2

    is obsolete, use mpQS part of more recent flint

    gap

    4.4.10.p2

    Depends on sbrk(), currently builds only via Cygwin. a cygwin build could be fine for us, since there is no binary linking between sage and gap, and almost certainly there never will be any.

    gap-guava

    gdmodule

    0.56.p4

    should be pretty easy to do for MSVC Boothby told me this swig-generated "crap" will be removed from sage soon, he hopes.

    genus2reduction

    0.3.p1

    unclear, don't really see any problem easy, probably; it's just math

    gfan

    0.2.2.p2

    unclear how hard the port will be, but shouldn't be too hard. we should upgrade to 0.2.3 first. Some more remarks: gfan requires argv[0] to switch to the right computation. I.e. during installation the following is executed: "ln -s gfan gfan_weightvector". This should be portable, but symlinks can be problematic on Windows.

    ipython

    0.8.1.p1

    should work fine with MSVC definitely will work fine.

    jinja

    XXXX

    jmol

    11.5.2.p1

    pure java, no portability issues, large community of users on Windows

    jsmath

    XXXX

    matplotlib

    0.91.1.p3

    should work with MSVC, more investigation is needed I'm sure this will work -- it is also part of what the enthought people distribute for windows.

    maxima

    5.13.0.p2

    Should build fine with Clisp, Windows binary package exists.

    mcube

    sage-notebook

    optimalrubik

    20070912.p1

    no Windows port, but simple C/C++ code without any POSIX dependencies. Console applications easy?

    palp

    1.1.p1

    unclear how hard the port will be, but shouldn't be too hard.

    pexpect

    2.0.p1

    Difficult. pexpect uses pseudo ttys and a whole bunch of POSIX infrastructure. It is essential and central to Sage and no one has ported pexpect to Windows. While the API is very different it is still possible to map all functionality to native Windows API calls. Instead of porting pexpect, it might be possible to do something different that accomplishes the same thing. pexpect was the way to go with Python and Unix. It's possibly OK if this means rewriting SAGE_ROOT/devel/sage/sage/interfaces/ for this new approach. Some of the programs Sage interfaces with have native "client server" archicture, and that could perhaps be used instead. E.g., Maple and Mathematica do. Maxima almost certainly doesn't...

    pycrypto

    2.0.1.p1

    unclear how hard the port will be, but shouldn't be too hard. maybe trivial??

    python_gnutls

    1.1.4.p2

    Should work, uses dlopen based mechanism. Is essential to the notebook, but can be dropped in favour of system's OpenSSL compatible library

    r

    2.6.1.p14

    Existing MinGW port, not too difficult to build. Port to MSVC desired. They don't already have a native MSVC port? Wow. That's amazing.

    sage-doc

    sage-latex

    http://rpy.sourceforge.net/ rpy

    1.0.1.p1

    Support for MSVC in 32 bit mode with MSVC. No Cygwin support, but patch by Abshoff exists

    sphinx

    XXXX

    sympow

    1.018.1.p4

    tricky code that needs the right FPU flags set. Otherwise no big hurdles to overcome

Packages without code

  • Website

    Win32

    Win64

    MSVC

    Version

    Comments

    conway_polynomials

    N/A

    N/A

    N/A

    0.2

    platform independent, i.e. no known Windows specific issues trivial -- just a pickle

    doc

    2.10.2.alpha0

    no compiled code, so no portability issues.

    elliptic_curves

    0.1

    elliptic curve database, so no porting issues

    graphs

    20070722

    graph database, so no porting issues

    polytopes