Information for the port to Cygwin64

The 64-bit version of Cygwin, also known as Cygwin64, is the current target for Sage support on Windows.

The instructions below have been integrated into the Sage README and installation manual for Sage 9.1 in . This page is archived; do not edit.

Building Sage on Cygwin

  1. Download cygwin64 (do not get the 32-bit version; it is not supported by Sage).
  2. Run the setup-x86_64.exe graphical installer. Pick the default options in most cases. When you reach the package selection screen, use the search bar to find and select the following minimal set of packages (we will install most packages later using a different tool): bzip2, coreutils, curl, gawk, gzip, tar, wget.
  3. Start the Cygwin terminal and ensure you get a working bash prompt.
  4. Install apt-cyg:
    $ curl -OL
    $ install apt-cyg /usr/local/bin
    $ rm -f apt-cyg
  5. Install the minimal build dependencies for Sage:
    $ apt-cyg install make m4 flex git gcc-core gcc-g++ gcc-fortran diffutils \
                      liblapack0 liblapack-devel zlib-devel libreadline-devel \
                      libiconv-devel libcrypt-devel openssl-devel gettext-devel \
                      python ccache
  6. (Optional) Install additional dependencies; this will allow building certain SPKGs to be skipped:
    $ apt-cyg install bc libbz2-devel libcurl-devel libffi-devel \
                      libgmp-devel liblzma-devel libmpc-devel \
                      libmpfr-devel libzmq-devel patch yasm
  7. Clone and enter the Sage Git repository:
    $ git clone --branch develop git://
    $ cd sage
  8. (Optional) Use Cygwin's default BLAS; this will save time on building OpenBLAS, but result in poorer performance on some BLAS functions. See #ChoosingaBLAS.
  9. (Optional) For parallel builds set the number of packages you want to build simultaneously; e.g.
    $ export MAKE='make -j4'
    to run 4 parallel makes.
  10. Build:
    $ make


Here is a quick checklist of steps to set up Cygwin and build Sage. The section following this one contains the same information in more detail.

Cygwin64 detailed building instructions

Sage on Cygwin is maintained currently primarily by embray. Sage on Cygwin has been stable since roughly SageMath 8.0. While there are still occasionally regressions, it is working most of the time.

Open issues for Cygwin64 can be found with this query. Not all of them are build-blockers.


Download and install cygwin64 (do not get the 32-bit version; it is not supported by Sage) and install the following packages: make, m4, flex, git, gcc-core, gcc-g++, gcc-fortran, diffutils, liblapack0, liblapack-devel, zlib-devel, libiconv-devel, libreadline-devel, libcrypt-devel, openssl-devel, python, wget.

You can install these manually by going through the list in the Cygwin installer, but it is faster and easier to skip this step and just use apt-cyg (see below). In order for apt-cyg to work you still need, at a minimum, wget is installed, along with any default packages.

Make sure to not install either of:

  • sqlite3-devel
  • libncurses-devel

Having these package installed can cause some Python extension modules to not build properly (due to a bug in the Python build system, see #22768) since Sage contains its own copies of sqlite3 and libncurses anyways.

Note that as of #27823, libiconv-devel is a required prerequisite for building the r package.

Setting your home directory

This is an optional step but might be useful. By default, your username in Cygwin is the same as your username in Windows. This might contain spaces and other traditionally non-UNIX-friendly characters, e.g. if it is your full name. For example, my username is:

$ whoami
Erik M. Bray

This means your default home directory on Cygwin contains this username verbatim; in my example /home/Erik M. Bray. There might still be some UNIX-oriented software that balks at this, so it might be less trouble if you change your home directory to something not containing any non-alphanumeric characters. The easiest way to do this I've found is to first create the home directory you want to use instead, then create an /etc/passwd file specifying that directory as your home, as follows (I use /home/embray as my home directory, for example):

$ mkdir /home/embray
$ mkpasswd.exe -l -u "$(whoami)" | sed -r 's|/home/[^:]+|/home/embray|' > /etc/passwd

Note that in the sed expression I have included my desired home directory in the replacement text. After this, close all Cygwin terminals (ensure nothing in C:\cygwin64 is running), then start a new Cygwin terminal and your home directory should be moved. There are many other ways to do this, but I find this to be the simplest that's still supported.

Using apt-cyg to install dependencies

It is recommended to install apt-cyg, a command-line tool for installing Cygwin packages (as opposed to using the old setup.exe). This makes it easier to install and upgrade packages after initial installation of Cygwin.

To install apt-cyg run:

curl -OL
install apt-cyg /usr/local/bin
rm -f apt-cyg

Note that for apt-cyg to actually work you need a few minimal packages installed in the first place, which you would install with the Cygwin installer. These include bzip2, coreutils, gawk, gzip, tar, wget. Most of these are almost always installed by default when you install Cygwin, with the notable exception of wget which is not.

With apt-cyg installed you can install the build prerequisites for Sage like:

apt-cyg install make m4 flex git gcc-core gcc-g++ gcc-fortran diffutils \
                liblapack0 liblapack-devel zlib-devel libreadline-devel \
                libiconv-devel libcrypt-devel openssl-devel python ccache

You can omit ccache if you want but so long as you have the disk space for a large .ccache it is well worth it.

The following additional dependencies are strongly recommended. If any of them are missing Sage has SPKGs for them that will be built and installed, but these dependencies can also be satisfied from the existing Cygwin packages, allowing skipping that additional build overhead:

apt-cyg install bc libbz2-devel libcurl-devel libffi-devel \
                libgmp-devel liblzma-devel libmpc-devel \
                libmpfr-devel libzmq-devel patch yasm

Downloading Sage

Open a cygwin terminal, go to the directory where you want to download sage, then type:

git clone git://
cd sage
git checkout develop
git checkout -b my_development_branch

The last line is purely optional/demonstrative. It's a good idea, if you might change any files, to start your own branch so as to not accidentally make commits to develop.

Building Sage

Choosing a BLAS

If you don't specify otherwise, Sage will build its own copy of OpenBLAS for use with Sage (there are plans to support Cygwin's existing openblas package but this is not implemented yet). On one hand, OpenBLAS will provide generally better performance than Cygwin's default BLAS. On the other hand it can take a fairly long time to build. If you want to avoid building OpenBLAS and just use the BLAS included by Cygwin's lapack package. (It should be noted that although the settings for this mention "ATLAS", these settings will actually just detect a generic BLAS on your system and it doesn't necessarily have to be ATLAS.)

Skip this step if you want to just build OpenBLAS:

export PREREQ_OPTIONS=--with-blas=atlas
export SAGE_ATLAS_LIB=/usr/lib

For a parallel build

export MAKE='make -j4'

(adjust the 4 to your number of cores, it should be a sensible default in most cases).

To build sage, type



Update: With #15423, it is rarely necessary to do this manually. All DLLs in Sage now get rebased automatically during building/rebuilding of packages. It might help to run rebaseall once immediately after installing Cygwin and and all the build dependencies to ensure that the DLL database is initialized with all the relevant system DLLs in Cygwin.

It is possible (likely?) that the compilation fails with strange error messages related to forking. This is an intrinsic limitation of cygwin. To solve it in most cases, quit all running cygwin applications and shells, edit the file local/bin/sage-rebase.bat, adjust the directory names as explained in this file, then execute sage-rebase.bat. Restart a cygwin shell and resume compilation by typing make in sage's directory, the problem should be solved.

A special case: if rebasing is needed while compiling a package, then rebasing and resuming compilation might not work, since the compilation of the package will restart from scratch. This happens especially with python, which creates a lot of shared libraries. A hackish workaround in this case:

  • rebase
  • in the file local/var/tmp/sage/build/python2-2.7.9/spkg-install, delete lines 25 to 32 (from PATCH to done)
  • open a cygwin shell, go to sage directory and type
    ./sage -sh
    cd local/var/tmp/sage/build/python2-2.7.9

This will resume (and hopefully complete, thanks to the rebase) the compilation of the partially compiled package python2-2.7.9, and install sane libraries. Then make will again try to compile python from scratch, it will likely fail, but since sane libraries have already been installed everything should work afterwards.

Additional Troubleshooting

Fork errors / segfaults during doc build

(Note: The Windows error code 0xc0000005 is STATUS_ACCESS_VIOLATION, i.e. a segfault--if you see this it means there was a segfault somewhere deep-enough in Cygwin that even Cygwin's error handling failed and did produce a SIGSEGV.)

Prior to Cygwin 2.8.0 it was common to get fork errors, even after a rebaseall, during the Sage documentation build (e.g. make doc) particularly with parallel doc builds (SAGE_NUM_THREADS > 1). This was due to a since-fixed bug in Cygwin related to recursive fork() calls where fork() is called from a thread. If you're having this problem first check your Cygwin version (uname -a) and make sure it's at least 2.8.0, and upgrade if not.

This bug can hypothetically affect other code, especially code using Python's multiprocessing.Pool (since calling fork() from a thread is exactly something it tends to do). But it comes up most commonly in the doc build.

Problems with git

Depending on the exact library versions, using the git from Cygwin can get messed up if you're in the Sage shell (e.g. in sage -sh). The reasons for this are detailed in #25816, but in short it's an example of DLL hell arising from the fact that git (as you may know) is actually built out of a whole mess of different executables, all of which are installed in Cygwin under /usr/libexec/git-core. The Sage shell messes with the $PATH variable such that the smaller programs that make up git can end up loading some of their dependent DLLs from $SAGE_LOCAL, which can break things if the library versions don't happen to be in sync. A workaround is to copy the necessary DLLs from /usr/bin into /usr/libexec/git-core--specifically only those DLLs that might be overridden by Sage. As of writing the only two such DLLs are:

  • cygiconv-2.dll
  • cygpcre-1.dll

However, a generic way to make this fixup is:

for dllname in $(cygcheck.exe /usr/libexec/git-core/*.exe | grep "$(cygpath -w -a $SAGE_LOCAL | sed 's/\\/\\\\/g')" | sed 's|.*\\\(.\+\.dll\)|\1|' | sort | uniq); do
    cp /usr/bin/$dllname /usr/libexec/git-core
Difficulties debugging with GDB

Because of the aforementioned need to rebase DLLs, debugging with GDB (or any debugger really) can become hampered. This is because much of the DWARF format debugging info the DLLs (found in the various .debug_ sections of the PE/COFF structure) is position-dependent. That is, it depends on the DLL's base address. If a DLL has to be relocated at link time that's okay--GDB can make the appropriate adjustments relative to the DLL's actual load address. However, the rebase utility does not fix up addresses in the DWARF sections, so as far as GDB is concerned the DWARF sections for such DLLs are just gibberish. As a simple example, the .debug_aranges section maps ranges of memory (in a position-dependent manner) to the compilation units (i.e. source files) associated with that range of memory (e.g. perhaps that range of memory contains code or data from a specific source file--this helps the debugger narrow in, for example, on the correct symbols associated with variables or functions in some address range). Because the addresses in this section and others (such as .debug_loc and .debug_frame are incorrect, GDB will not set breakpoints correctly, etc.

Ideally this should be fixed in rebase, which should read the DWARF sections and fix up addresses in them appropriately. However, this would be somewhat non-trivial--straightforward in principle but a lot of work to get right. So when debugging, it's best to temporarily disable rebasing (I comment out the lines in sage-spkg and src/Makefile that perform the rebasing, but it might be better to have an environment variable to control this) and reinstall the relevant packages for debugging. This isn't a problem as long as fork() isn't involved. If it is then things get trickier, and it's better to try to narrow down the problem to something simpler.

Old Stuff

Everything below this line is old notes from earlier Cygwin port attempts. Most of it is no longer relevant but is kept here for possible historical interest.


Testing Sage 5.9 on Windows 7 64 bits with Cygwin 64 1.7.19

  • Some packages ship config.guess scripts which fail to recognize Cygwin64, this is #14648.
  • Cygwin64's GCC (4.8.0) uses libraries similar to what Sage builds. As the Sage libraries are located in $PATH they get picked up when Cygwin's GCC is run and it can segfault, see, see #14697, #10572.
  • iconv 1.13.x does not build, this is #14647.
  • Python (and libffi within) needs patching, this is #14600.
  • boehm_gc will need heavy patching, see and following posts, the cygwin maintainer in charge of libgc has crafted a package following Corinna instructions, we can use the patch from there (provided we clean it up). This is #14710.
  • ecl fails to build with a segfault when trying to use ecl_min. This has been reported on different systems (at least I've had the same problem on a non Cygwin machine, have to find where it was, and could workaround it by lowering optimization, it does not work on my Cygwin64 install):
  • givaro fails to build, being unable to detect mpir c++ bindings, because the mpir build seems in fact very broken, have to investigate.
  • Indeed MPIR is completely broken. To get it to build a little more correctly (it seems there are problem left with long long size), follow: This is #15015.

That's all I've done for the moment.

Testing 5.10 on Windows 7 64 bits with Cygwin 64

  • zlib 1.2.8 does not build, this is #14985. True for Cygwin 32 and 64.

Testing 5.11.rc0 on Windows XP 32 bits

  • ppl 1.0 uses some libm "long double" functions, e.g. frexpl, that Cygwin's libm does not provide. True for Cygwin 32 and 64. This is fixed in 1.1.pre*. See also This is now #15001.
  • ntl won't build because is only build as a static library. gf2x should be modified to pass the -no-undefined flag to libtool and build a shared library, see the related #13354. This is #15014.
  • I'm unable to build the doc in parallel, or using Pool even with one thread. I had to completely disable the use of Pool/fork as is done on the FreeBSD port. Then everything went fine. That may be because Sage is now too big and completely fills the address space available to Cygwin 32. In fact it seems that it is because two dll produced by sage are named function.dll and the windows loader cannot tell the difference and miserably fails... See #15338.

Testing Sage 5.12 on Windows XP 32 bits (running within VirtualBox? 4.3) with Cygwin 32

Testing Sage 5.12 on Windows 7 64 bits (running within VirtualBox? 4.3) with Cygwin32

  • Problem with gf2x because tuning needs to execute a file with update in its name. See #15339.

Testing Sage 5.13 on Windows XP 32 bits (running within VirtualBox? 4.3) with Cygwin 32

  • Mostly same problems as with 5.12.
  • gf2x needs some work to be built without optimization, see #15316 where upstream patches will be packed at some point.
  • fflas-ffpack use a wrong ATLAS, see #14390 were patches will hopefully be posted.
  • Fixes for python at #15317 and ncurses at #15617.
  • To build Sage's GCC, use #15365 for MPIR and #15366 for GCC 4.7.3. For GCC 4.8.2, #15323 would also be needed/
  • The libtool project for ATLAS was not updated... so use #15615.
  • Some files in the Sage library needs more linking, see #15630.
  • With all of that everything builds fine! Just a little bit of rebasing needed.
  • Problem when building the doc. Fork error involving linbox.dll, not sure why, rebasing does not solves that on my current setup. It seems the linbox address space collides with the one from some comctl32.dll... It seems the address space needed by Sage dlls is getting quite large, especially that we ship two copies of every compile cython module, I'll modify the Sage's rebase scripts to only take the runtime copy of this modules only once which save a lot of space already and so makes address collisions less likely. See #15649.

Testing Sage 5.13 on Windows 7 64 bits (running within VirtualBox? 4.3) with Cygwin 64

  • Modified MPIR spkg-install to let it build 64 bits and updated configfsf.* scripts so that they recognize Cygwin64, use #15365, #14648 and #15651.
  • Note that #14648 is also needed for ECL, sqlite, IML.
  • ncurses from #15617 failed with an ICE while compiling test/tclock.c. Passing CFLAGS="-O0 -g" let it build.
  • Same same for glpk as for ncurses, but CFLAGS="-O0 -g" does not help.
  • Same same for python as for glpk, with CFLAGS="-O0 -g" not helping. Apparently GCC raises its ICE in both cases when compiling log.
  • In fact, at least the two previous errors (and surely the third one) are because the system wide gcc picks up Sage mpir/mpfr/mpc. Using compilerwrapper from #10572 solves the ICE.
  • PPL fails because the weak symbol ppl_unreachable is put into the shared ppl lib, but not the import ppl lib, and so the C interface ppl_c lib fails to link with an undefined symbol. This surely is a Cygwin64's gcc/g++/binutils bug. As a temp workaround, disable the PPL_WEAK_NORETURN magic in src/ppl.hh. Use #16152.
  • For gf2x use #15339.
  • ATLAS fails with ATL_dset_xp1yp0aXbX.c:86:5: erreur: #error "This kernel requires a gas x86 assembler!" when using SAGE_FAT_BINARY as it explicitely use ISA extensions and the win64 abi is not the amd64 one and the ATLAS assembly cannot be used. Easy to fix: don't explicitly pass isa extensions in the generic arch used for ATLAS on Cygwin64, see #15615.
  • gdmodule fails with undefined symbols in freetype. Looking at it, it's strange that freetype was only built as a static archive, libtool complaining that -lz did not yield a real linker path, but zlib was installed correctly??? The include libtool is just too old... this affects (at least) libpng (solved by autorevonf -fiv), freetype (solved by ./, gd (solved by autoreconf -fiv). See #15677.
  • numpy fails when linking to atlas, more precisely using ptcblas and atlas, but the former is static and the latter shared, it may be a remain of my different attempts to build ATLAS, but potentially the way we install ATLAS needs more thoughts. Removing the harmful libpt*.a static lib let numpy build. No ticket open yet, I'll have to see what a clean install does first, but at least a workaround is mentioned here.
  • r failed: ld doesn't like --large-address-aware. Removing its use fixes the issue. See #15678.
  • Some files in the Sage library needs more linking, see #15630.
  • Linking to singular fails, surely because the library is named and ld perhaps does not look for this extension anymore. Copying it to libsingular.dll (is dirty bu) works. See #15679.
  • sagenb fails while installing webassets with a segfault. More precisely, python segfaults when executing "from sphinx.setup_command import BuildDoc?", in Objects/fileobject.c:457 Py_END_ALLOW_THREADS, in close_the_file function with arg a null pointer. Surely an heisenfix, but after aplying it seems the segfault is gone. See also the uuid.patch shipped by Cygwin but it did not seem enough for me. See #16119.
  • I had to rebase to build the doc.
  • Tada, first Sage Cygwin64 build?
  • segfaults when using libsingular in omGetBackTrace with bts like
    (gdb) bt
    #0  0x00000003bea0bc0c in omGetBackTrace ()
       from /home/jp/sage-5.13/local/lib/
    #1  0x00000003bea07794 in omAllocTrackAddr ()
       from /home/jp/sage-5.13/local/lib/
    #2  0x000006fffd63909c in ?? ()
    #3  0x00000003c5ee2077 in PyTuple_New ()
       from /home/jp/sage-5.13/local/bin/libpython2.7.dll
    #4  0x0000000600eec730 in ?? ()
    #5  0x0000000601082720 in ?? ()
    #6  0x000006fffd625d70 in ?? ()
    #7  0x00000003e1802908 in __pyx_f_4sage_4libs_8singular_8function_9Converter_append_str(__pyx_obj_4sage_4libs_8singular_8function_Converter*, _object*) ()
       from C:/cygwin64/home/jp/sage-5.13/devel/sage-main/build/sage/libs/singular/function.dll
    It seems after a very quick and unprofessional test that disabling the use of omGetBackTrace à la fixes the problem. Added to #15679 as well.
  • sqlite doesn't seem so happy, maybe What's funny is that tests in sage/databases/ fail with ./sage -t but succeed with ./sage-t --gdb :)

Testing Sage 6.2.beta4 on Windows 7 64 bits (running within VirtualBox?) with Cygwin 64

  • On top of the 5.13 issues which were not fixed...
  • Updated freetype wants to link to bz2 but bz2 only produces a static lib... autotoolified version at #15967 which produces shared and static bz2 libs.
  • rpy2 does not compile. One has to tweak na_values.c and _rinterface.c to treat __CYGWIN__ like Win32/64. rinterface should also be linked to readline. See #16089.
  • Updated sqlite at #16098, libpng at #16099, gmp stripped ecl at #9493.
  • ATLAS fix at #16112.
  • Use MPIR from #15015, still troubles with PPL...

Testing Sage 6.4.rc2 on Windows 7 64 bits (running within VirtualBox?) with Cygwin 32

Testing Sage 6.4.rc2 on Windows 7 64 bits (running within VirtualBox?) with Cygwin 64

  • Same setup as above.
  • ATLAS needs patching or it uses some MSVCRT thread related functions and linking fails. See #17365.
  • Wow!!! a lot of things seem to work. Let's just note among other things that PARI does not think that 131 is prime :)

Testing Sage 6.5.beta5 on Windows 7 64 bits with Cygwin 64

  • With correct zeromq fix from #17622.
  • ATLAS fix from #17365.
  • Linking fixes from #17619.
  • fflas-ffpack does not find ATLAS built by Sage, see #17630.

Testing Sage 6.5.beta5 on Windows 7 64 bits with Cygwin 32

Testing Sage 6.9.beta3 on Windows 7 64 bits with Cygwin 64

  • Everything compiles out of the box, rebase needed to start building the docs.
  • Doc building does not finish, probably some race condition.
  • alarm is broken, fixed in #17650 (this patch is needed to test the whole library, otherwise some tests run forever and eat up all the memory).
  • With this patch, one can test the whole library. There are relatively few failing doctests!
  • Most failing doctests are related to singular. Hopefully fixed or at least improved by #17254.
  • ecm seems also broken.
  • #17864 fixes one doctest due to bad signal handling in cygwin.
  • numpy does not raise division by zero errors. Fixed in the upcoming version 1.10.0 of numpy.
Last modified 20 months ago Last modified on 06/03/20 06:02:10