| 2 | | As of Sage 5.8.beta3, Sage should build "out of the box" with a Cygwin that has the same prereqs as any other Sage, and start, with two exceptions. See #6743 or below for more details. |
| 3 | | * Rebase/forking problems |
| 4 | | * #13351 will need to be applied during the build process. |
| | 2 | As of Sage 5.9.beta4, Sage should build "out of the box" with a Cygwin that has the same prereqs as any other Sage, with the very minor caveats below, and start. See #6743 or below for more details. The only exception is that rebase and forking problems continue (see below and #14031). The ''only'' special prerequisites are |
| | 3 | * That the gcc versions must match, if you install gcc4-core, gcc4-gfortran, and gcc4-g++ (with just gcc4-core, Sage's gcc 4.7 gets built) |
| | 4 | * That we need libmpfr4 in addition |
| | 5 | * That we need liblapack-devel and lapack |
| | 6 | We no longer need `SAGE_PORT=yes`, as of this release! |
| 36 | | At any point in the build process (or after), one can get forking problems, related to the fact that Windows can relocate a dynamic library that just called fork() to another place in memory, causing fork() failure (this is a "feature" of the current Cygwin fork() implementation on Win32). To decrease the probability of this happening, you may need to rebase all the Cygwin and Sage DLLs you have so far, i.e. allocate each its own space address to load in (otherwise they compete for the space). |
| | 38 | At any point in the build process (or after), one can get forking problems, related to the fact that Windows can relocate a dynamic library that just called fork() to another place in memory, causing fork() failure (this is a "feature" of the current Cygwin fork() implementation on Win32). To decrease the probability of this happening, you may need to rebase all the Cygwin and Sage DLLs you have so far, i.e. allocate each its own space address to load in (otherwise they compete for the space). |
