Building Sage with Cygwin 32 bit

[Evan Oman]

Hi all,

I am trying to build Sage 6.1 from source on Cygwin(something I have seen lots of support pages about so I hope this isn't a repost). 

I have all the required packages and everything runs smoothly until the Python install section of the build where I get the following error:

--Begin Message--

running install_scripts

copying build/scripts-2.7/2to3 -> /home/evan.oman/sage-6.1/local/bin

copying build/scripts-2.7/idle -> /home/evan.oman/sage-6.1/local/bin

copying build/scripts-2.7/pydoc -> /home/evan.oman/sage-6.1/local/bin

copying build/scripts-2.7/smtpd.py -> /home/evan.oman/sage-6.1/local/bin

changing mode of /home/evan.oman/sage-6.1/local/bin/2to3 to 775

changing mode of /home/evan.oman/sage-6.1/local/bin/idle to 775

changing mode of /home/evan.oman/sage-6.1/local/bin/pydoc to 775

changing mode of /home/evan.oman/sage-6.1/local/bin/smtpd.py to 775

running install_egg_info

Removing /home/evan.oman/sage-6.1/local/lib/python2.7/lib-dynload/Python-2.7.5-py2.7.egg-info

Writing /home/evan.oman/sage-6.1/local/lib/python2.7/lib-dynload/Python-2.7.5-py2.7.egg-info

rm /home/evan.oman/sage-6.1/local/lib/python2.7/lib-dynload/_sysconfigdata.py*

if test -f /home/evan.oman/sage-6.1/local/bin/python.exe -o -h /home/evan.oman/sage-6.1/local/bin/python.exe; \

then rm -f /home/evan.oman/sage-6.1/local/bin/python.exe; \

else true; \

fi

(cd /home/evan.oman/sage-6.1/local/bin; ln -s python2.exe python.exe)

rm -f /home/evan.oman/sage-6.1/local/bin/python2.exe

(cd /home/evan.oman/sage-6.1/local/bin; ln -s python2.7.exe python2.exe)

rm -f /home/evan.oman/sage-6.1/local/bin/python2-config

(cd /home/evan.oman/sage-6.1/local/bin; ln -s python2.7-config python2-config)

rm -f /home/evan.oman/sage-6.1/local/bin/python-config

(cd /home/evan.oman/sage-6.1/local/bin; ln -s python2-config python-config)

test -d /home/evan.oman/sage-6.1/local/lib/pkgconfig || /usr/bin/install -c -d -m 755 /home/evan.oman/sage-6.1/local/lib/pkgconfig

rm -f /home/evan.oman/sage-6.1/local/lib/pkgconfig/python2.pc

(cd /home/evan.oman/sage-6.1/local/lib/pkgconfig; ln -s python-2.7.pc python2.pc)

rm -f /home/evan.oman/sage-6.1/local/lib/pkgconfig/python.pc

(cd /home/evan.oman/sage-6.1/local/lib/pkgconfig; ln -s python2.pc python.pc)

rm -f /home/evan.oman/sage-6.1/local/share/man/man1/python2.1

(cd /home/evan.oman/sage-6.1/local/share/man/man1; ln -s python2.7.1 python2.1)

rm -f /home/evan.oman/sage-6.1/local/share/man/man1/python.1

(cd /home/evan.oman/sage-6.1/local/share/man/man1; ln -s python2.1 python.1)

make[3]: Leaving directory '/home/evan.oman/sage-6.1/local/var/tmp/sage/build/python-2.7.5.p1/src'

Testing importing of various modules...

ctypes module imported OK

math module imported OK

hashlib module imported OK

crypt module imported OK

Traceback (most recent call last):

  File "<string>", line 1, in <module>

ImportError: No module named readline

readline module failed to import

socket module imported OK

Error: One or more modules failed to import.

--End Message--

and then this: 

--Begin Message--

***************************************************************

Error building Sage.

The following package(s) may have failed to build:

package: python-2.6.4.p1

log file: /home/evan.oman/sage-6.1/logs/pkgs/python-2.6.4.p1.log

build directory: /home/evan.oman/sage-6.1/local/var/tmp/sage/build/python-2.6.4.p1

package: python-2.6.4.p11

log file: /home/evan.oman/sage-6.1/logs/pkgs/python-2.6.4.p11.log

build directory: /home/evan.oman/sage-6.1/local/var/tmp/sage/build/python-2.6.4.p11

package: python-2.7.5.p1

log file: /home/evan.oman/sage-6.1/logs/pkgs/python-2.7.5.p1.log

build directory: /home/evan.oman/sage-6.1/local/var/tmp/sage/build/python-2.7.5.p1

package: python-2.7.5.p11

log file: /home/evan.oman/sage-6.1/logs/pkgs/python-2.7.5.p11.log

build directory: /home/evan.oman/sage-6.1/local/var/tmp/sage/build/python-2.7.5.p11

The build directory may contain configuration files and other potentially

helpful information. WARNING: if you now run 'make' again, the build

directory will, by default, be deleted. Set the environment variable

SAGE_KEEP_BUILT_SPKGS to 'yes' to prevent this.

Makefile:19: recipe for target 'build' failed

make: *** [build] Error 1

--End Message--

What I was wondering is if this is an indication that I should undergo rebasing(is that still a thing that needs to be done on 6.1?) or something a little more straightforward(like forcing/rearranging things so this one module will import). 

I am running cygwin 32 bit on Windows 8.1 

Thanks in advance!

Also if this is a repost I apologize and will visit the correct support ticket/forum page.

[Dima Pasechnik]

On 2014-03-10, Evan Oman <eva...@gmail.com> wrote:
> Hi all,
>
> I am trying to build Sage 6.1 from source on Cygwin(something I have seen
> lots of support pages about so I hope this isn't a repost).
>
> I have all the required packages and everything runs smoothly until the
> Python install section of the build where I get the following error:

[...]

> Traceback (most recent call last):
> File "<string>", line 1, in <module>
> ImportError: No module named readline
> readline module failed to import

this looks like the readline module did not build correctly.
Look at the appropriate place of the log.
Usually you will find a fork error message there, meaning that you
have to rebase manually...

BTW, I don't see why you have so many different Python packages that failed
to build!
There should be just one...

HTH,
Dima

>
> The following package(s) may have failed to build:
>
> package: python-2.6.4.p1
> log file: /home/evan.oman/sage-6.1/logs/pkgs/python-2.6.4.p1.log
> build directory:
> /home/evan.oman/sage-6.1/local/var/tmp/sage/build/python-2.6.4.p1
>
> package: python-2.6.4.p11
> log file: /home/evan.oman/sage-6.1/logs/pkgs/python-2.6.4.p11.log
> build directory:
> /home/evan.oman/sage-6.1/local/var/tmp/sage/build/python-2.6.4.p11
>
> package: python-2.7.5.p1
> log file: /home/evan.oman/sage-6.1/logs/pkgs/python-2.7.5.p1.log
> build directory:
> /home/evan.oman/sage-6.1/local/var/tmp/sage/build/python-2.7.5.p1
>
> package: python-2.7.5.p11
> log file: /home/evan.oman/sage-6.1/logs/pkgs/python-2.7.5.p11.log
> build directory:
> /home/evan.oman/sage-6.1/local/var/tmp/sage/build/python-2.7.5.p11
>
> The build directory may contain configuration files and other potentially
> helpful information. WARNING: if you now run 'make' again, the build
> directory will, by default, be deleted. Set the environment variable
> SAGE_KEEP_BUILT_SPKGS to 'yes' to prevent this.
>
> Makefile:19: recipe for target 'build' failed
> make: *** [build] Error 1
>

> *--End Message--*

[Evan Oman]

Within the readline module log? 

Everything seems to be fine in there, here is the last bit of the readline log:

make[4]: Leaving directory '/home/evan.oman/sage-6.1/local/var/tmp/sage/build/readline-6.2.p4/src/doc'

( cd shlib ; make -w DESTDIR= install )

make[4]: Entering directory '/home/evan.oman/sage-6.1/local/var/tmp/sage/build/readline-6.2.p4/src/shlib'

/bin/sh ../support/mkdirs /home/evan.oman/sage-6.1/local/lib

/bin/sh ../support/mkdirs /home/evan.oman/sage-6.1/local/bin

/bin/sh ../support/shlib-install -O cygwin -V pc -d /home/evan.oman/sage-6.1/local/lib -b /home/evan.oman/sage-6.1/local/bin -i "/usr/bin/install -c -m 644" cyghistory6.dll

/bin/sh ../support/shlib-install -O cygwin -V pc -d /home/evan.oman/sage-6.1/local/lib -b /home/evan.oman/sage-6.1/local/bin -i "/usr/bin/install -c -m 644" cygreadline6.dll

install: you may need to run ldconfig

make[4]: Leaving directory '/home/evan.oman/sage-6.1/local/var/tmp/sage/build/readline-6.2.p4/src/shlib'

make[3]: Leaving directory '/home/evan.oman/sage-6.1/local/var/tmp/sage/build/readline-6.2.p4/src'

Fixing permissions of libraries...

real    0m55.455s

user    0m17.571s

sys     0m30.534s

Successfully installed readline-6.2.p4

Deleting temporary build directory

/home/evan.oman/sage-6.1/local/var/tmp/sage/build/readline-6.2.p4

Finished installing readline-6.2.p4.spkg

Also I have no idea where all those different python versions came from.

[Dima Pasechnik]

On 2014-03-11, Evan Oman <eva...@gmail.com> wrote:
> *Within the readline module log? *

no, in the python log (it's most probable that the building of
python's readline extension failed).
(and/or in the full install.log)



>
> *Everything seems to be fine in there, here is the last bit of the readline
> log:*
>

[Jean-Pierre Flori]

You can have a look at http://trac.sagemath.org/wiki/Cygwin64Port.
My last try was with 5.13 on Cygwin64, but some of the issues can be 32/64 agnostic and 5.13 and 6.1 are not that different.
The only one on the page which might affect you at this pooint is either rebasing or a problem with system-wide/sage local mpir/mpfr/mpc making gcc segfault.

And we would need the part about readline in the python log as Dima pointed out, and what happens when you enter a sage shell, go to the python build dir, launch the python there and type import readline.

[Jean-Pierre Flori]

In fact you would need http://trac.sagemath.org/ticket/15317 which is merged but in a 6.2 beta.

[mmarco]

Is it possible now to build sage on cygwin and obtain something that can be distributed? In that case, maybe we should include that in the download section.

[Jean-Pierre Flori]

On Tuesday, March 11, 2014 10:20:08 AM UTC+1, mmarco wrote:

Is it possible now to build sage on cygwin and obtain something that can be distributed? In that case, maybe we should include that in the download section.

I'd say mostly yes, just like on linux.
But some people said we should have something even more easy to install, i.e. include Sage, but all parts of cygwin needed.

Occasionally I do package some binary things with the sage part (so you have to install cygwin, the needed dependencies, and potentially rebase and update hardcoded paths), without any promise it's working.
At least the initial install is working in the VMs I use.

IIRC last time Harald put some of these tarballs somewhere on the net (or maybe that was solaris trarballs), that's all I know.

Without a VM running somewhere I or someone else can access all the time, it won't be easy to automate such a task.

[Dima Pasechnik]

On 2014-03-11, Jean-Pierre Flori <jpf...@gmail.com> wrote:
>
>
> On Tuesday, March 11, 2014 10:20:08 AM UTC+1, mmarco wrote:
>>
>> Is it possible now to build sage on cygwin and obtain something that can
>> be distributed? In that case, maybe we should include that in the download
>> section.
>>
> I'd say mostly yes, just like on linux.
> But some people said we should have something even more easy to install,
> i.e. include Sage, but all parts of cygwin needed.

probably the most natural thing to do would be to make a Sage Cygwin
package hosted on a custom Cygwin setup server:
https://sourceware.org/cygwin-apps/package-server.html

Dima

[mmarco]

That is what singular does, right?

[Evan Oman]

Alright so I have attached the entire Python log so hopefully that will contain what you were looking for. 

Starting a sage shell, running its python, and typing import readline yields:

>>> import readline

Traceback (most recent call last):

  File "<stdin>", line 1, in <module>

ImportError: No module named readline

Also I started fresh from a new tarball and that fixed the multiple versions of python issue but the build stopped at the same point(trying to import readline).

Thank you all for your willingness to help!

[Jean-Pierre Flori]

I did not look at the logs yet, but you definitely need python 2.7.5.p2 which is not in the 6.1 series.
See http://trac.sagemath.org/ticket/15317

[Evan Oman]

Awesome, installing python 2.7.5.p2  got me past the readline error and it continued building from there. 

It ran for about 30 minutes(running a ton of sanity tests, a good sign?), then froze here for an hour or two:

/cygdrive/c/cygwin//home/evan.oman/sage-6.1/local/var/tmp/sage/build/atlas-3.10.1.p7/src/ATLAS-build/../ATLAS//src/blas/level2//ATL_trsv.c: In function ‘ATL_trsvUN_k’:

/cygdrive/c/cygwin//home/evan.oman/sage-6.1/local/var/tmp/sage/build/atlas-3.10.1.p7/src/ATLAS-build/../ATLAS//src/blas/level2//ATL_trsv.c:105:6: warning: assignment discards ‘const’ qualifier from pointer target type [enabled by default]

    a = A + ((size_t)lda2)*(N-nb);

      ^

ar r /cygdrive/c/cygwin//home/evan.oman/sage-6.1/local/var/tmp/sage/build/atlas-3.10.1.p7/src/ATLAS-build/lib/libatlas.a ATL_L2AIsOverlapped.o ATL_sgbmv.o ATL_sgpmv.o ATL_sgpr.o ATL_ssbmv.o ATL_sspmv.o ATL_sspr.o ATL_sspr2.o ATL_ssymv.o ATL_ssyr.o ATL_ssyr2.o ATL_stbmv.o ATL_stbsv.o ATL_stpmv.o ATL_stpsv.o ATL_strmv.o ATL_strsv.o

echo /cygdrive/c/cygwin//home/evan.oman/sage-6.1/local/var/tmp/sage/build/atlas-3.10.1.p7/src/ATLAS-build/lib/libatlas.a

/cygdrive/c/cygwin//home/evan.oman/sage-6.1/local/var/tmp/sage/build/atlas-3.10.1.p7/src/ATLAS-build/lib/libatlas.a

touch sblas2.grd

make[7]: Leaving directory '/cygdrive/c/cygwin/home/evan.oman/sage-6.1/local/var/tmp/sage/build/atlas-3.10.1.p7/src/ATLAS-build/src/blas/level2'

make[6]: Leaving directory '/cygdrive/c/cygwin/home/evan.oman/sage-6.1/local/var/tmp/sage/build/atlas-3.10.1.p7/src/ATLAS-build/tune/blas/ger'

make[5]: Leaving directory '/home/evan.oman/sage-6.1/local/var/tmp/sage/build/atlas-3.10.1.p7/src/ATLAS-build/bin'

I decided to cancel the build and I am rerunning it now, wish me luck!

[Evan Oman]

Hmm, it is just sitting there on that line again, is it expecting input? It seems to be passing all of the tests.

[Jean-Pierre Flori]

Tuning ATLAS is slow.

[Dima Pasechnik]

On 2014-03-12, Evan Oman <eva...@gmail.com> wrote:
> Hmm, it is just sitting there on that line again, is it expecting input? It
> seems to be passing all of the tests.

you might instead just install the relevant Cygwin libs, and use them,
instead of building Altas.
See SAGE_ATLAS_LIB in
http://www.sagemath.org/doc/installation/source.html#environment-variables

[Jean-Pierre Flori]

Not sure this works anymore (because of me...).

[Jean-Pierre Flori]

Just checked and it should still work.
But note that the use of ATLAS in Sage on Cygwin (and other systems) is kind of hackish and broken.
See http://trac.sagemath.org/ticket/14390 and http://trac.sagemath.org/ticket/15839

[Evan Oman]

False alarm, I let it sit overnight and it appeared to pass after about 6 hours of running. 

However, no surprise, another package halted the build with the error: 

cat ../gf2x/gf2x-thresholds.h > tuned_thresholds.h

./update-thresholds -o tuned_thresholds.h < tunetoom.res

/bin/sh: ./update-thresholds: Permission denied

Makefile:2205: recipe for target 'tune-toom' failed

make[4]: *** [tune-toom] Error 126

make[4]: Leaving directory '/home/evan.oman/sage-6.1/local/var/tmp/sage/build/gf2x-1.1.p0/src/src'

Makefile:976: recipe for target 'tune-toom' failed

make[3]: *** [tune-toom] Error 2

make[3]: Leaving directory '/home/evan.oman/sage-6.1/local/var/tmp/sage/build/gf2x-1.1.p0/src'

Error: Failed to tune gf2x.

What does it mean "Permission Denied"? Is that something to do with my system configuration and permissions?

I tried installing the spkg here but that didn't work and there seems to be some relevant discussion here along with a patch but I am not sure how to apply it or if it addresses my issue. 

This is beginning to seem like an exercise in futility, suppose thats what might happen when you try to use things that "Almost Work" haha.

Thank you all again for putting up with my amateur questions!

[Dima Pasechnik]

On 2014-03-12, Evan Oman <eva...@gmail.com> wrote:
> False alarm, I let it sit overnight and it appeared to pass after about 6
> hours of running.
>
> However, no surprise, another package halted the build with the error:
>
> cat ../gf2x/gf2x-thresholds.h > tuned_thresholds.h
> ./update-thresholds -o tuned_thresholds.h < tunetoom.res
> /bin/sh: ./update-thresholds: Permission denied
> Makefile:2205: recipe for target 'tune-toom' failed
> make[4]: *** [tune-toom] Error 126
> make[4]: Leaving directory
> '/home/evan.oman/sage-6.1/local/var/tmp/sage/build/gf2x-1.1.p0/src/src'
> Makefile:976: recipe for target 'tune-toom' failed
> make[3]: *** [tune-toom] Error 2
> make[3]: Leaving directory
> '/home/evan.oman/sage-6.1/local/var/tmp/sage/build/gf2x-1.1.p0/src'
> Error: Failed to tune gf2x.
>
> What does it mean "Permission Denied"? Is that something to do with my
> system configuration and permissions?

it probably just means that the file update-thresholds does not have
executable permissions.
Can you cd to the appropriate directory (probably to
/home/evan.oman/sage-6.1/local/var/tmp/sage/build/gf2x-1.1.p0/src)
and run
ls -l update-thresholds

(and post the output here)

[Jean-Pierre Flori]

Nope, the problem is that it contains update in its name so requires admin rights from windows 7 (or vista).
See http://trac.sagemath.org/ticket/15339

[Evan Oman]

Yep the admin thing did it, successfully installed gf2x. Don't know why I wasn't running cygwin as admin the entire time....

But now I got an error on Pillows which I understand to be an image manipulation liubrary for python:

/home/evan.oman/sage-6.1/local/var/tmp/sage/build/freetype-2.5.2.p0/src/src/bzip2/ftbzip2.c:198: undefined reference to `BZ2_bzDecompressEnd'

/home/evan.oman/sage-6.1/local/lib/libfreetype.a(ftbzip2.o): In function `ft_bzip2_file_fill_output':

/home/evan.oman/sage-6.1/local/var/tmp/sage/build/freetype-2.5.2.p0/src/src/bzip2/ftbzip2.c:303: undefined reference to `BZ2_bzDecompress'

/home/evan.oman/sage-6.1/local/lib/libfreetype.a(ftbzip2.o): In function `ft_bzip2_file_reset':

/home/evan.oman/sage-6.1/local/var/tmp/sage/build/freetype-2.5.2.p0/src/src/bzip2/ftbzip2.c:227: undefined reference to `BZ2_bzDecompressEnd'

/home/evan.oman/sage-6.1/local/var/tmp/sage/build/freetype-2.5.2.p0/src/src/bzip2/ftbzip2.c:238: undefined reference to `BZ2_bzDecompressInit'

/home/evan.oman/sage-6.1/local/lib/libfreetype.a(ftbzip2.o): In function `ft_bzip2_file_init':

/home/evan.oman/sage-6.1/local/var/tmp/sage/build/freetype-2.5.2.p0/src/src/bzip2/ftbzip2.c:183: undefined reference to `BZ2_bzDecompressInit'

collect2: error: ld returned 1 exit status

error: command 'gcc' failed with exit status 1

Error building / installing Pillow

I tried to install the tarball attached here but I think that it is the same one distributed with sage.

Also I found a mention of the Pillow install problem here and they said that it was an easy fix though I did not follow how the suggestion would solve the issue.

[Evan Oman]

Oh and here is the full Pillow log. It seems to fail after trying this:

building 'PIL._imagingft' extension

I remember that being mentioned somewhere but without a solution.

[Jean-Pierre Flori]

I would need the bz2 and freetype logs.

[Evan Oman]

Ahh, they are attached.

Also I found a stack exchange article here, is this the same issue? I do have libfreetype installed for sure though so I don't think thats my problem.

[Jean-Pierre Flori]

This might just be another issue like in http://trac.sagemath.org/ticket/15677
Or the order in which arguments are fed to libtool: "-lz -lbz2 -L/home/evan.oman/sage-6.1/local/lib -lpng12 -no-undefined".
Whatsoever, it seems freetype decided not to find the bz2 lib and only built a static archive.

So the only solution I'm thinking about is to modify/patch the freetype archive so that it builds a shared lib and then we'll see what happens.
You might just decompress the freetype tarball, run "./autogen.sh" on a recent linux system with tautotools installed, retar it, update the checksums and try to reinstall it.
If freetype does not build a shared lib though, then you'll have to patch the makefiles to modidy the order of the linking flags.

[Evan Oman]

I tried the autogen idea with my virtual Ubuntu 12.04, ran the autogen.sh, retared it, and tried reinstalling but with no avail. Here was the end of the make output:

collect2: error: ld returned 1 exit status

error: command 'gcc' failed with exit status 1

Error building / installing Pillow

real    0m18.865s

user    0m12.932s

sys     0m4.965s

************************************************************************

Error installing package pillow-2.2.2

************************************************************************

Please email sage-devel (http://groups.google.com/group/sage-devel)

explaining the problem and including the relevant part of the log file

  /home/evan.oman/sage-6.1/logs/pkgs/pillow-2.2.2.log

Describe your computer, operating system, etc.

If you want to try to fix the problem yourself, *don't* just cd to

/home/evan.oman/sage-6.1/local/var/tmp/sage/build/pillow-2.2.2 and type 'make' or whatever is appropriate.

Instead, the following commands setup all environment variables

correctly and load a subshell for you to debug the error:

  (cd '/home/evan.oman/sage-6.1/local/var/tmp/sage/build/pillow-2.2.2' && '/home/evan.oman/sage-6.1/sage' --sh)

When you are done debugging, you can type "exit" to leave the subshell.

************************************************************************

Makefile:850: recipe for target '/home/evan.oman/sage-6.1/local/var/lib/sage/installed/pillow-2.2.2' failed

make[2]: *** [/home/evan.oman/sage-6.1/local/var/lib/sage/installed/pillow-2.2.2] Error 1

make[2]: Leaving directory '/home/evan.oman/sage-6.1/build'

Makefile:374: recipe for target 'all' failed

make[1]: *** [all] Error 2

make[1]: Leaving directory '/home/evan.oman/sage-6.1/build'

real    0m21.132s

user    0m13.386s

sys     0m6.202s

***************************************************************

Error building Sage.

The following package(s) may have failed to build:

package: pillow-2.2.2

log file: /home/evan.oman/sage-6.1/logs/pkgs/pillow-2.2.2.log

build directory: /home/evan.oman/sage-6.1/local/var/tmp/sage/build/pillow-2.2.2

The build directory may contain configuration files and other potentially

helpful information. WARNING: if you now run 'make' again, the build

directory will, by default, be deleted. Set the environment variable

SAGE_KEEP_BUILT_SPKGS to 'yes' to prevent this.

Makefile:19: recipe for target 'build' failed

Is this a new error or a different version of the same old thing?

Also what do you mean by update the check sums? Is this done automatically with the tar command?

So if it looks like patching is my only options what changes would I make and in what file would I make them?

[Evan Oman]

Attached are the pillow, bz2, and freetype logs.

[Jean-Pierre Flori]

I reproduced the problem and finally narrowed the issue:
* bzip2 only produces a static lib,
* freetype 2.3.5 which we used to ship did not use bz2, whereas freetype 2.5.2 does.
* libtool refuses to put the static lib within the shared one (on Cygwin, no problem on Linux).

[Evan Oman]

So would a solution be to somehow roll back my version of freetype then? Or would a more aggressive patch be required?

[Jean-Pierre Flori]

On Friday, March 14, 2014 4:57:33 PM UTC+1, Evan Oman wrote:

So would a solution be to somehow roll back my version of freetype then? Or would a more aggressive patch be required?

That should work unless something in Sage explicitely relies on new features of freetype (if there are any).

[Evan Oman]

Alright I found an old version of freetype in a spkg on here, installed it, and the build continued and installed pillow successfully.

After successfully installing several other components I got a build fail with this message at the end:

Compiling sage/ext/interpreters/wrapper_el.pyx because it changed.

      0 [main] python2.7 5460 child_info_fork::abort: address space needed by 'unicodedata.dll' (0x790000) is already occupied

Traceback (most recent call last):

  File "setup.py", line 536, in <module>

    force=force)

  File "/home/evan.oman/sage-6.1/local/lib/python2.7/site-packages/Cython/Build/Dependencies.py", line 746, in cythonize

    pool = multiprocessing.Pool(nthreads)

  File "/home/evan.oman/sage-6.1/local/lib/python/multiprocessing/__init__.py", line 232, in Pool

    return Pool(processes, initializer, initargs, maxtasksperchild)

  File "/home/evan.oman/sage-6.1/local/lib/python/multiprocessing/pool.py", line 159, in __init__

    self._repopulate_pool()

  File "/home/evan.oman/sage-6.1/local/lib/python/multiprocessing/pool.py", line 222, in _repopulate_pool

    w.start()

  File "/home/evan.oman/sage-6.1/local/lib/python/multiprocessing/process.py", line 130, in start

    self._popen = Popen(self)

  File "/home/evan.oman/sage-6.1/local/lib/python/multiprocessing/forking.py", line 121, in __init__

    self.pid = os.fork()

OSError: [Errno 11] Resource temporarily unavailable

real    0m4.865s

user    0m2.546s

sys     0m2.248s

Makefile:822: recipe for target '/home/evan.oman/sage-6.1/local/var/lib/sage/installed/sage' failed

make[2]: *** [/home/evan.oman/sage-6.1/local/var/lib/sage/installed/sage] Error 1

make[2]: Leaving directory '/home/evan.oman/sage-6.1/build'

Makefile:374: recipe for target 'all' failed

make[1]: *** [all] Error 2

make[1]: Leaving directory '/home/evan.oman/sage-6.1/build'

real    0m5.656s

user    0m2.788s

sys     0m2.796s

***************************************************************

Error building Sage.

The following package(s) may have failed to build:

The build directory may contain configuration files and other potentially

helpful information. WARNING: if you now run 'make' again, the build

directory will, by default, be deleted. Set the environment variable

SAGE_KEEP_BUILT_SPKGS to 'yes' to prevent this.

Makefile:19: recipe for target 'build' failed

make: *** [build] Error 1

Which looks to me like a rebasing issue. So I started up ASH and ran the rebaseall command as per the instructions here however restarting Cygwin and running make again resulted in the same message.

I did see another suggestion to entirely remove the "BLODA" software listed here because this software may scramble things and cause issues. I noticed that I may have 3 of the listed programs(Avast, Lenovo stuffs, and NVIDIA stuffs)  which I am not sure would worth it to me to remove(they said disabling would not cut it).

Any thoughts?

[Dima Pasechnik]

On 2014-03-14, Evan Oman <eva...@gmail.com> wrote:
> Alright I found an old version of freetype in a spkg on here, <http://www.filewatcher.com/m/freetype-2.3.5.p4.spkg.1300660-0.html>installed

> it, and the build continued and installed pillow successfully.
>
> After successfully installing several other components I got a build fail
> with this message at the end:
>
> Compiling sage/ext/interpreters/wrapper_el.pyx because it changed.
> 0 [main] python2.7 5460 child_info_fork::abort: address space needed
> by 'unicodedata.dll' (0x790000) is already occupied
> Traceback (most recent call last):
> File "setup.py", line 536, in <module>
> force=force)

[...]

> Which looks to me like a rebasing issue. So I started up ASH and ran the

> rebaseall command as per the instructions here<http://cygwin.wikia.com/wiki/Rebaseall> however

> restarting Cygwin and running make again resulted in the same message.
>

> I did see another suggestion to *entirely remove *the "BLODA" software
> listed here <http://cygwin.com/faq/faq.html#faq.using.bloda> because this

> software may scramble things and cause issues. I noticed that I may have 3
> of the listed programs(Avast, Lenovo stuffs, and NVIDIA stuffs) which I am
> not sure would worth it to me to remove(they said disabling would not cut
> it).
>
> Any thoughts?

Note that "rebaseall" does not rebase all the things needed to be
rebased, as they sit in non-standard directories. Sage does provide
custom rebase scripts, see http://trac.sagemath.org/ticket/14031
These are MSDOS batch files sage-rebaseall.bat and sage-rebase.bat
Read
http://trac.sagemath.org/attachment/ticket/14031/trac_14031-scripts.patch
for more details.

HTH,
Dmitrii

PS. my experinece with 32-bit Cygwin was awful - I was never able to
finish the build, due to these rebasing issues.

[Jean-Pierre Flori]

I think the easiest way to deal with rebasing right now is to run:
* cd $SAGE_ROOT && find . -name "*.dll" > dlls && rebase -O -T dlls

[Jean-Pierre Flori]

For the only static bz2 issue, I opened http://trac.sagemath.org/ticket/15967.
I just slightly modified the existing makefile.
Another solution might be to use the autotools build system made by the mingw folk (and use by the cygwin folk, not sure what linux distros do).

[Evan Oman]

Where should I run this from? ASH console, command prompt, cygwin, or sage shell? Also should I replace $SAGE_ROOT with my path? Or is that some sort of path variable. 

[Jean-Pierre Flori]

On Tuesday, March 18, 2014 3:13:32 AM UTC+1, Evan Oman wrote:

Where should I run this from? ASH console, command prompt, cygwin, or sage shell? Also should I replace $SAGE_ROOT with my path? Or is that some sort of path variable. 

You can run it from bash, even without admin privilege.
And yes, you have to replace SAGE_ROOT witht the actual path from your sage install

[Jean-Pierre Flori]

By the way, some really easy tickets need review for the Cygwin 64 port where there should be less rebasing issues:
* http://trac.sagemath.org/ticket/15366 for GCC 4.7.3.
* http://trac.sagemath.org/ticket/15678 for R (upstream does not care, I provided a patch and they just closed the bug report saying they don't care).
* http://trac.sagemath.org/ticket/15679 for Singular.
* http://trac.sagemath.org/ticket/15651 for MPIR.
* http://trac.sagemath.org/ticket/15316 for GF2X.
* http://trac.sagemath.org/ticket/10572 for messed up LD_LIBRARY_PATH.

Some others need more love:
* http://trac.sagemath.org/ticket/15323 for GCC 4.8.x.
* http://trac.sagemath.org/ticket/14648 for old config scripts.
* http://trac.sagemath.org/ticket/15677 for old libtool.
* http://trac.sagemath.org/ticket/13354 for shared libs.
And a bunch of other ones.

[Evan Oman]

That line doesn't seem to change anything for me, I will have to try some of the other rebasing scripts that Dima mentioned. I will let you know if I find anything that works. 

[Jean-Pierre Flori]

On Tuesday, March 18, 2014 4:11:12 PM UTC+1, Evan Oman wrote:

That line doesn't seem to change anything for me, I will have to try some of the other rebasing scripts that Dima mentioned. I will let you know if I find anything that works. 

There is little hope...
Make sure that inside the "dlls" file created by the find command, dll's from sage are listed.
It may also be the case that you just have two many process running in Windows and Cygwin and that collisions cannot be avoided.
Contrary to Karl-Dieter I'm usually able to build Sage on Cygwin32 but my Windows install is minimal as I don't really use it for anything else.

Your best chance is to issue "./sage -b", wait for it to fail, run the rebase command I gave, rerun "./sage -b".
Don't use make as it will restart compilation of the sage library file from scratch each time.
If that succeed, you can then touch the file indicating that the sage library was successfully installed and go on with the few spkgs not yet installed.

[Evan Oman]

Alright here is the latest error after running the -b version of build, doesn't mention any dll's but is it the same issue? 

Compiling sage/ext/interpreters/wrapper_el.pyx because it changed.

Cythonizing sage/algebras/letterplace/free_algebra_element_letterplace.pyx

Traceback (most recent call last):

  File "setup.py", line 536, in <module>

Cythonizing sage/gsl/interpolation.pyx

    force=force)

  File "/home/evan.oman/sage-6.1/local/lib/python2.7/site-packages/Cython/Build/Dependencies.py", line 747, in cythonize

Cythonizing sage/media/channels.pyx

    pool.map(cythonize_one_helper, to_compile)

  File "/home/evan.oman/sage-6.1/local/lib/python/multiprocessing/pool.py", line 250, in map

Cythonizing sage/rings/number_field/totallyreal.pyx

    return self.map_async(func, iterable, chunksize).get()

  File "/home/evan.oman/sage-6.1/local/lib/python/multiprocessing/pool.py", line 554, in get

    raise self._value

AttributeError: 'Cython.Plex.Actions.Call' object has no attribute 'perform'

Also I have attached the dlls file, seems to be finding the files we want.

So about the minimal install thing, is there a start up mode(like safe mode) where I can run only the bare essentials of windows? Seems like there should be a way to only run a specific few programs(but maybe not, I have no idea).

[Jean-Pierre Flori]

On Friday, March 21, 2014 9:31:40 PM UTC+1, Evan Oman wrote:

Alright here is the latest error after running the -b version of build, doesn't mention any dll's but is it the same issue? 

Compiling sage/ext/interpreters/wrapper_el.pyx because it changed.

Cythonizing sage/algebras/letterplace/free_algebra_element_letterplace.pyx

Traceback (most recent call last):

  File "setup.py", line 536, in <module>

Cythonizing sage/gsl/interpolation.pyx

    force=force)

  File "/home/evan.oman/sage-6.1/local/lib/python2.7/site-packages/Cython/Build/Dependencies.py", line 747, in cythonize

Cythonizing sage/media/channels.pyx

    pool.map(cythonize_one_helper, to_compile)

  File "/home/evan.oman/sage-6.1/local/lib/python/multiprocessing/pool.py", line 250, in map

Cythonizing sage/rings/number_field/totallyreal.pyx

    return self.map_async(func, iterable, chunksize).get()

  File "/home/evan.oman/sage-6.1/local/lib/python/multiprocessing/pool.py", line 554, in get

    raise self._value

AttributeError: 'Cython.Plex.Actions.Call' object has no attribute 'perform'

No idea at first...

FYI, I successfully compiled 6.2.beta5 within a 32 bit Windows XP VM using the fix for bzip2 at http://trac.sagemath.org/ticket/15967 (and nothing more IIRC).
Wouldn't you mind trying to follow the same route?
It should be easier to debug.
(On Windows 7, you would also need http://trac.sagemath.org/ticket/15339 or pass SAGE_TUNE_GF2X=no which should disable tuning and give you a slower GF2X but easier to get compiled.)

[Evan Oman]

Alright so I downloaded 6.2 beta 5, ran it, and fixed a couple issues with that rebasing script you gave me and other things that we figured out before. 

I do think the build has progressed more than my previous attempts but now it got stuck with this error:

====================================================

Setting up build directory for rpy2-2.3.8

Finished set up

****************************************************

...

copying ./rpy/interactive/tests/__init__.py -> build/lib.cygwin-1.7.28-i686-2.7/rpy2/interactive/tests

running build_ext

"/home/evan.oman/sage-6.2-beta5/sage-6.2.beta5/local/lib/R/bin/R" CMD config --ldflags

"/home/evan.oman/sage-6.2-beta5/sage-6.2.beta5/local/lib/R/bin/R" CMD config --cppflags

"/home/evan.oman/sage-6.2-beta5/sage-6.2.beta5/local/lib/R/bin/R" CMD config LAPACK_LIBS

returned an empty string.

returned an empty string.

"/home/evan.oman/sage-6.2-beta5/sage-6.2.beta5/local/lib/R/bin/R" CMD config BLAS_LIBS

returned an empty string.

returned an empty string.

Configuration for R as a library:

  include_dirs: ('/home/evan.oman/sage-6.2-beta5/sage-6.2.beta5/local/lib/R//include',)

  libraries: ('R',)

  library_dirs: ('/home/evan.oman/sage-6.2-beta5/sage-6.2.beta5/local/lib/R//lib', '/home/evan.oman/sage-6.2-beta5/sage-6.2.beta5/local/lib')

  extra_link_args: ()

 # OSX-specific (included in extra_link_args)

  framework_dirs: ()

  frameworks: ()

building 'rpy2.rinterface._rinterface' extension

creating build/temp.cygwin-1.7.28-i686-2.7

creating build/temp.cygwin-1.7.28-i686-2.7/rpy

creating build/temp.cygwin-1.7.28-i686-2.7/rpy/rinterface

gcc -I/usr/include/ncurses -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -DR_INTERFACE_PTRS=1 -DHAVE_POSIX_SIGJMP=1 -DRIF_HAS_RSIGHAND=1 -DCSTACK_DEFNS=1 -DHAS_READLINE=1 -I./rpy/rinterface -I/home/evan.oman/sage-6.2-beta5/sage-6.2.beta5/local/include/python2.7 -I/home/evan.oman/sage-6.2-beta5/sage-6.2.beta5/local/lib/R//include -c ./rpy/rinterface/_rinterface.c -o build/temp.cygwin-1.7.28-i686-2.7/./rpy/rinterface/_rinterface.o

In file included from ./rpy/rinterface/_rinterface.c:124:0:

./rpy/rinterface/na_values.c:209:9: error: initializer element is not constant

         &PyLong_Type,           /*tp_base*/

         ^

./rpy/rinterface/na_values.c:209:9: error: (near initialization for 'NAInteger_Type.tp_base')

./rpy/rinterface/na_values.c:407:9: error: initializer element is not constant

         &PyLong_Type,             /*tp_base*/

         ^

./rpy/rinterface/na_values.c:407:9: error: (near initialization for 'NALogical_Type.tp_base')

./rpy/rinterface/na_values.c:593:9: error: initializer element is not constant

         &PyFloat_Type,             /*tp_base*/

         ^

./rpy/rinterface/na_values.c:593:9: error: (near initialization for 'NAReal_Type.tp_base')

./rpy/rinterface/na_values.c:695:9: error: initializer element is not constant

         &PyString_Type,             /*tp_base*/

         ^

./rpy/rinterface/na_values.c:695:9: error: (near initialization for 'NACharacter_Type.tp_base')

./rpy/rinterface/na_values.c:862:9: error: initializer element is not constant

         &PyComplex_Type,             /*tp_base*/

         ^

./rpy/rinterface/na_values.c:862:9: error: (near initialization for 'NAComplex_Type.tp_base')

In file included from ./rpy/rinterface/_rinterface.c:125:0:

./rpy/rinterface/sexp.c: In function 'Sexp_rclass_set':

./rpy/rinterface/sexp.c:369:5: warning: return makes integer from pointer without a cast [enabled by default]

     return NULL;

     ^

./rpy/rinterface/sexp.c: In function 'Sexp_init':

./rpy/rinterface/sexp.c:711:13: warning: unused variable 'copy' [-Wunused-variable]

   PyObject *copy = Py_True;

             ^

In file included from ./rpy/rinterface/_rinterface.c:104:0:

./rpy/rinterface/_rinterface.c: At top level:

./rpy/rinterface/embeddedr.h:20:20: warning: '_Rpy_PreserveObject' declared 'static' but never defined [-Wunused-function]

 static SexpObject* _Rpy_PreserveObject(SEXP object);

                    ^

In file included from ./rpy/rinterface/_rinterface.c:129:0:

./rpy/rinterface/sequence.c:2190:1: warning: 'ComplexVectorSexp_AsSexp' defined but not used [-Wunused-function]

 ComplexVectorSexp_AsSexp(PyObject *pyfloat) {

 ^

error: command 'gcc' failed with exit status 1

real    0m1.977s

user    0m0.397s

sys     0m0.933s

************************************************************************

Error installing package rpy2-2.3.8

************************************************************************

I thought it might have something to do with this http://trac.sagemath.org/ticket/13350 but I am not sure how to apply the patch listed there(if it is needed on 6.2).

[Jean-Pierre Flori]

Nope, but I do remember getting this.
I'll try to retrieve the patch I used.

[Jean-Pierre Flori]

IIRC, you should modify lines like the following one:
https://bitbucket.org/lgautier/rpy2/src/a66387e12e2419141dadb7464ea9205595ef89af/rpy/rinterface/na_values.c?at=default#cl-206
to include __CYGWIN__ in addition to Win32 and Win64.

[Jean-Pierre Flori]

Same in this file:
https://bitbucket.org/lgautier/rpy2/src/a66387e12e2419141dadb7464ea9205595ef89af/rpy/rinterface/_rinterface.c?at=default#cl-3385
(only for the tp_base stuff I'd say)

[Sebastien Gouezel]

I am also trying to compile sage (6.2 beta 4) under Cygwin. I got a
working copy of sage, but the doc does not build (so, I can not try
"make test"). Here is the beginning of the log:

Building reference manual, first pass.

[combinat ] Configuration error:
[combinat ] There is a syntax error in your configuration file: invalid
syntax (conf.py, line 1)
[polynomia] Configuration error:
[polynomia] There is a syntax error in your configuration file: invalid
syntax (conf.py, line 1)
[cmd ] Configuration error:
[cmd ] There is a syntax error in your configuration file: invalid
syntax (conf.py, line 1)

And the list goes on like that for most directories, only [riemannia]
succeeds.
(the file combinat/conf.py is simply "../conf_sub.py").
Any idea?


For the record, here are the steps I followed to compile sage:

- the patch trac.sagemath.org/ticket/15967 is necessary.

- there are problems in rpy2. As mentioned in the previous message, one
should add __CYGWIN__ in addition to Win32 and Win64 several times in
rinterface/na_values.c. However, this is not enough: one still gets the
following error

gcc -shared -Wl,--enable-auto-image-base
-L/home/Sebastien/sage-git/sage/local/lib
build/temp.cygwin-1.7.28-i686-2.7/./rpy/rinterface/_rinterface.o
-L/home/Sebastien/sage-git/sage/local/lib/python2.7/config
-L/home/Sebastien/sage-git/sage/local/lib
-L/home/Sebastien/sage-git/sage/local/lib/R//lib
-L/home/Sebastien/sage-git/sage/local/lib/R/modules -lR -lpython2.7 -lR
-o build/lib.cygwin-1.7.28-i686-2.7/rpy2/rinterface/_rinterface.dll
build/temp.cygwin-1.7.28-i686-2.7/./rpy/rinterface/_rinterface.o: In
function `EmbeddedR_init':
/home/Sebastien/sage-git/sage/local/var/tmp/sage/build/rpy2-2.3.8/src/./rpy/rinterface/_rinterface.c:1333:
undefined reference to `rl_completer_word_break_characters'
/home/Sebastien/sage-git/sage/local/var/tmp/sage/build/rpy2-2.3.8/src/./rpy/rinterface/_rinterface.c:1334:
undefined reference to `rl_completer_word_break_characters'
/home/Sebastien/sage-git/sage/local/var/tmp/sage/build/rpy2-2.3.8/src/./rpy/rinterface/_rinterface.c:1336:
undefined reference to `rl_basic_word_break_characters'
/home/Sebastien/sage-git/sage/local/var/tmp/sage/build/rpy2-2.3.8/src/./rpy/rinterface/_rinterface.c:1337:
undefined reference to `rl_basic_word_break_characters'

collect2: error: ld returned 1 exit status

error: command 'gcc' failed with exit status 1

(linking problem with readline, likely). I commented out the offending
lines in _rinterface.c (I know this is not a proper fix, of course, but
it is sufficient to get things to compile).

- I had to rebase once.

- Segmentation faults during zn_poly's tuning (in KS/FFT mul). Looks
like http://trac.sagemath.org/ticket/13947. On the third attempt,
everything went smoothly.

[Sebastien Gouezel]

Le 06/04/2014 13:45, Sebastien Gouezel a écrit :
> I am also trying to compile sage (6.2 beta 4) under Cygwin. I got a
> working copy of sage, but the doc does not build (so, I can not try
> "make test"). Here is the beginning of the log:
>
> Building reference manual, first pass.
>
> [combinat ] Configuration error:
> [combinat ] There is a syntax error in your configuration file: invalid
> syntax (conf.py, line 1)

> (the file combinat/conf.py is simply "../conf_sub.py").

The problem is that git on windows (msysgit) converts symlinks to text
files containing the address of the symlinked file. So, it has nothing
to do with sage, it is a problem with msysgit.

Scripts to restore the symlinks are available at
http://stackoverflow.com/questions/5917249/git-symlinks-in-windows

[Jean-Pierre Flori]

Good news.

If you're actually interested in Sage on Cygwin32/64, please don't be shy and review some of the easy tickets needing review.
See everyt link not green at http://trac.sagemath.org/wiki/Cygwin64Port (where I now report for goth Cygwin32/64).

[Evan Oman]

Alright so total noob question here but how do I make these changes to the rpy2 files?

I tried unpacking the tarball in the upstream folder(??), made the appropriate changes, and then repackaged it but now I get a checksum error. Is there some sort of touch or other command I need to use to update the checksums? Or am I going about this in the entirely wrong way?

[Jean-Pierre Flori]

On Sunday, April 6, 2014 11:34:45 PM UTC+2, Evan Oman wrote:

Alright so total noob question here but how do I make these changes to the rpy2 files?

I tried unpacking the tarball in the upstream folder(??), made the appropriate changes, and then repackaged it but now I get a checksum error. Is there some sort of touch or other command I need to use to update the checksums? Or am I going about this in the entirely wrong way?

Go to the root of your sage install and run:
./sage -sh -c sage-fix-pkg-checksums

[Jean-Pierre Flori]

or without the -c, don't remember.

[Evan Oman]

Awesome, thanks

I tried adding

 || defined(_CYGWIN_)

every time I saw

defined(Win32) || defined(Win64)

but I am still getting the same error. 

I tried changing the files so that everything would break and it did so I think my changes are being implemented in the sage build. 

I have attached both of the files mentioned, do you guys see anywhere I am going wrong?

[Sebastien Gouezel]

Le 08/04/2014 20:52, Evan Oman a écrit :

> I tried adding
> |
> ||defined(_CYGWIN_)

There should be two underscores on each side of CYGWIN, i.e., __CYGWIN__
instead of _CYGWIN_

[Evan Oman]

AHA! That did it!

So along with commenting out the lines in _rinterface that Sebastien mentioned I have a running Sage install! 

I do have the same documentation issue it seems so I will try the proposed msysgit fix and let you know if that works for me.

Thank you all so much for your help!!!

[Dima Pasechnik]

On 2014-04-08, Evan Oman <eva...@gmail.com> wrote:
>
>
><https://lh3.googleusercontent.com/-oJq3iWFDFmg/U0RoSaeJluI/AAAAAAAADMQ/yQhAr6gT1Z8/s1600/Screenshot+%282%29.png>

> AHA! That did it!
>
> So along with commenting out the lines in _rinterface that Sebastien
> mentioned I have a running Sage install!
>
> I do have the same documentation issue it seems so I will try the proposed
> msysgit fix and let you know if that works for me.

can't you just use git from Cygwin instead?

[Jean-Pierre Flori]

On Wednesday, April 9, 2014 12:06:14 AM UTC+2, Dima Pasechnik wrote:

On 2014-04-08, Evan Oman <eva...@gmail.com> wrote:
>
>
><https://lh3.googleusercontent.com/-oJq3iWFDFmg/U0RoSaeJluI/AAAAAAAADMQ/yQhAr6gT1Z8/s1600/Screenshot+%282%29.png>
> AHA! That did it!
>
> So along with commenting out the lines in _rinterface that Sebastien
> mentioned I have a running Sage install!
>
> I do have the same documentation issue it seems so I will try the proposed
> msysgit fix and let you know if that works for me.
can't you just use git from Cygwin instead?

Sure you could, that's what I do (within a VM running on Linux)...