Friday, December 28, 2007

Porting Sage 2.9.1.1 to Cygwin

We used to run Sage on Windows on top of Cygwin. When libSingular became a standard component of Sage around the 2.5.1 release the Cygwin port was dropped because Martin Albrecht and I were unable to get libSingular to link against the Sage extension on Cygwin. Both of us spend about a week attempting to fix the issue, but we never found a solution. Since Sage on Cygwin didn't pass a lot of other doctests we finally decided to drop the port and use the VMWare image as the only way to run Sage on Windows.

Recently I came up with some ideas how to solve the libSingular as well as some of the relocation problems that we had on Cygwin. This attempt was also in no small part motivated by a push to get on the way to a native Sage on Windows, discussed in a previous blog post of mine. Over the last 36 hours [of which I slept about 1/4 waiting on some compilation to finish] I finally took the time again to see how much trouble it is to get Sage 2.9.1.1 to compile via Cygwin. It wasn't pretty, but I got nearly all of Sage to compile with fixes/updates to the following spkgs.
  • gmp
  • cremona
  • opencdk
  • libgpg-error
  • libgcrypt
  • GNUTLS
  • gdmodule
  • linbox
  • matplotlib
  • mpfi
  • quaddouble
  • Singular
  • libfplll
  • polybori
  • rpy
  • rubiks
  • sage-2.9.1.1
Note that I am only discussing the compilation of Sage, I have been unable to actually import any of those Sage modules. I suspect suspect either a broken python install [rpy fails to import as well as matplotlib hangs for hours at 99% cpu use, but numpy imports just fine] and/or some issue with the way libcsage.dll is now build. Consquently I have been unable to doctest the resulting build so far. I will try to build Sage on Cygwin again with my fixes merged probably in the 2.10 time frame as it will take quite a while to clean it all up and feed it back into the build system. Some of the build issues are generic in nature, others can be quickly fixed by adapting the spkg-install script while most actually required fixes to the sources of the spkgs themselves. I plan to clean up the fixes and push them all upstream to their respective maintainers, so that we can avoid patching the code ourselves in the future. It is amazing how just seven months time makes a port bitrot and in that time frame the build system on Cygwin didn't change at all. I was also quite surprised how much open source software out there doesn't compile on Cygwin out of the box. Oh well, the port to MSVC will take more than 36 hours and will be much more painful. Sometimes I wonder if I shouldn't do more useful things in my spare time :)

Cheers,

Michael

No comments: