windows/general-package-analysis

Clear message

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
  blas	Y	Y	N/A	20070724	works fine with GNU make and Intel Fortran compiler
  bzip2	Y	P	P	1.0.4	works fine with MSVC (32 bits at least) - required by python
  cliquer	N	N	N	XXXX	Docs say minor changes to source required for non-unix OSs
  ecl	Y	P	Y	XXXX	See MSVC 2008 and MSVC 2008 Redistributable Package(64)
  eclib				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.
  flint				1.06.p1	C99 based code, build system easy enough, Windows specific fixes welcome upstream. Hooked deeply into GMP. Main developer -- Bill Hart -- uses Windows all the time.
  fplll				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?
  g95				20071120.p3	Part of MinGW 32 and 64 - does not need to be ported to MSVC
  gd				2.0.33.p5	port exists: http://gnuwin32.sourceforge.net/packages/gd.htm. Since that port uses MinGW we need to either use MinGW 64 bit or do an MSVC port ourselves.
  givaro				3.2.6.p6	no port exists, C++ code uses templates and it migt. be a little tricky to get right. Upstream welcomes patches could be hard.
  glpk				XXXX
  iml				1.0.1.p9	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				20071123.p0	Works out of the box with GNU make.
  lcalc				20070107.p1	somewhat crafty C code, ugly hacks in the user interface, but should be portable to MSVC. Builds fine under Cygwin
  libpng				1.2.22.p5	port exists: http://gnuwin32.sourceforge.net/packages/libpng.htm. 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.
  linbox				20070915.p5	this will be some heavy lifting, mostly due to some heavy templated code. Upstream is willing to merge and help out.
  mpfi				1.3.4-cvs20071125.p5	depends on mpfr and gmp, pure C library. Port is simple and will probably be merged upstream
  mpir	Y	Y	Y	XXXX	MPIR on Windows

• openssl					required by Python - builds fine with MSVC (32 bits at least)
  pari				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.
  polybori				0.1-r7	no Windows port, could be tricky, but upstream is willing to cooperate. worry??
  pynac				XXXX
  python				2.5.1.p13	excellent support for MSVC, 32 & 64 bit mode. yep, very very good support on windows
  ratpoints				XXXX
  readline				5.2.p0	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.
  singular				3-0-4-1-20071209.p4	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.
  sqlite				3.5.3.p1	pure Windows port exists (see http://www.sqlite.org/download.html), required by Python - builds fine with MSVC (32 bits at least)
  symmetrica				2.0.p1	no Windows port yet, but macro heavy. worrisome.
  tcl					Required by Python's IDLE - builds fine with MSVC (32 bits at least)
  tk					Required by Python's IDLE - builds fine with MSVC (32 bits at least)
  znpoly				XXXX

Unknown dependencies of Sage (not listed on sage-on-gentoo list)

• Website	Win32	Win64	MSVC	Version	Comments
  boost	Y	P	P	XXXX
  cephes	N	N	N		Last updated circa 1994, small library, but uses long doubles - only used in the Cygwin port so far (and FreeBSD in future)
  docutils				XXXX
  f2c				20070816.p0	part of scikits, should work with MSVC
  freetype				2.3.5	unclear if it is even required on Windows.
  gc				XXXX
  gnutls				2.2.1.p1	Shortly the spkgs for libgpg_error, libgcrypt and opencdk will disappear since gnutls now includes copies of them. gnutls has build support for 32 bit MSVC, the feasability of the 64 bit build needs to be investigated. Problems might crop up with inline assembly. maybe there is a native windows library that provides similar functionality. This is only needed so Twisted works with Python, and I'm sure that is already very well supported.
  libgcrypt				1.4.0.p0
  libgpg_error				1.6.p0
  mercurial				0.9.5.p0	some C extensions, maybe some portability issues, might need some TLC for various config issues
  opencdk				0.6.6
  pil				XXXX
  sage_scripts				2.10.2.alpha0	requires POSIX shell
  setuptools				XXXX
  sqlalchemy				XXXX
  termcap				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.

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, but should build fine once FLINT works, C99 mode required
  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

Do not correspond to Sage spkgs (elsewhere or no longer used in Sage?)

• Website	Win32	Win64	MSVC	Version	Comments
  mwrank				XXXX	Is this now eclib in Sage??

No longer listed on sagemath.org and not included as spkgs

• Website	Win32	Win64	MSVC	Version	Comments
  dir				0.1	requires POSIX shell
  openopt				XXXX
  prereq				0.3	requires POSIX shell - small build system issues

Packages with upstream MSVC support

• Website	Win32	Win64	MSVC	Version	Comments
  atlas				3.8.p11	Works find fine, Intel C for better performance preferred
  ecm				6.1.3	no Windows port, but C, potentially issues with threading. Upstream ecm-6.2 has MSVC project by Brian Gladman - upgrading evm to the 6.2 release is #3237
  gsl				1.10.p0	port exists: http://gnuwin32.sourceforge.net/packages/gsl.htm. Brian Gladman also maintains a native MSVC port, 32 & 64 bit.
  m4ri				20071224.p1	MSVC and SunForte port done by Martin Albrecht and in upstream. Upgrade ticket is #3204
  mpfr				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
  numpy				20080104-1.0.4.p2	support by enthought, builds out of the box with MSVC + ATLAS
  scipy				20071020-0.6.p3	support by enthought, builds out of the box with MSVC + ATLAS
  scipy_sandbox				20071020.p2	support by enthought, builds out of the box with MSVC + ATLAS
  scons				0.97	works fine on Windows, python based.
  tachyon				0.98beta.p4	Windows port exists, unsure about MSVC + threading.
  weave				0.4.9	now part of scikits, works fine with MSVC
  zlib				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.
  zodb				3.7.0.p0	mostly python, unknown difficulty to port probably easy

Pure Python Packages

• Website	Win32	Win64	MSVC	Version	Comments
  cython	N/A	N/A	N/A	0.9.6.12	pure python, no portability issues, might needs some TLC for various config issues my impression from cython-devel is that there are already numerous windows users of cython
  moin				1.5.7.p2	python based, should work fine on Windows
  mpmath				XXXX
  networkx				0.36.p1	pure python, no portability issues
  sympy				0.5.7	pure python, no portability issues.
  twisted				2.5.0.p9	python, is supported, relevant to notebook

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