New MPIR won't build on Cygwin

[kcrisman]

The recent MPIR versions can only be built shared OR static on Cygwin, not both. Moreover, MPIR configure scripts gets confused if Cygwin, which is only 32 bits, is ran on a 64 bits Windows.

Hence the following spkg sets ABI=32 (to tackle the second problem) and only builds a shared version of the library (to tackle the first one).

​http://boxen.math.washington.edu/home/jpflori/mpir-2.4.0.p7.spkg

Updated spkg based on this one at #13137. Please use the one there.

[kcrisman]

I fixed this with a jury-rigged spkg ​here. Patch attached, just for reference.

Next error:

Making all in yasm
make[4]: Entering directory `/home/Administrator/sage-4.8.alpha3/spkg/build/mpir-2.1.3.p8/src/yasm'
gcc -std=gnu99 -I.  -c -o genperf.o `test -f tools/genperf/genperf.c || echo './'`tools/genperf/genperf.c
gcc -std=gnu99 -I.  -c -o gp-perfect.o `test -f tools/genperf/perfect.c || echo './'`tools/genperf/perfect.c
gcc -std=gnu99 -I.  -c -o gp-phash.o `test -f libyasm/phash.c || echo './'`libyasm/phash.c
gcc -std=gnu99 -I.  -c -o gp-xmalloc.o `test -f libyasm/xmalloc.c || echo './'`libyasm/xmalloc.c
gcc -std=gnu99 -I.  -c -o gp-xstrdup.o `test -f libyasm/xstrdup.c || echo './'`libyasm/xstrdup.c
gcc -std=gnu99 -o genperf.exe  genperf.o gp-perfect.o  gp-phash.o gp-xmalloc.o gp-xstrdup.o
./genperf.exe x86insn_nasm.gperf x86insn_nasm.c
found distinct (A,B) on attempt 19
built perfect hash table of size 512
./genperf.exe x86insn_gas.gperf x86insn_gas.c
found distinct (A,B) on attempt 1640
built perfect hash table of size 512
gcc -std=gnu99 -I.  -c -o re2c-main.o `test -f tools/re2c/main.c || echo './'`tools/re2c/main.c
gcc -std=gnu99 -I.  -c -o re2c-code.o `test -f tools/re2c/code.c || echo './'`tools/re2c/code.c
gcc -std=gnu99 -I.  -c -o re2c-dfa.o `test -f tools/re2c/dfa.c || echo './'`tools/re2c/dfa.c
gcc -std=gnu99 -I.  -c -o re2c-parser.o `test -f tools/re2c/parser.c || echo './'`tools/re2c/parser.c
Makefile:3665: recipe for target `re2c-parser.o' failed
make[4]: *** [re2c-parser.o] Error 1
make[4]: Leaving directory `/home/Administrator/sage-4.8.alpha3/spkg/build/mpir-2.1.3.p8/src/yasm'
Makefile:772: recipe for target `all-recursive' failed
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/home/Administrator/sage-4.8.alpha3/spkg/build/mpir-2.1.3.p8/src'
Makefile:603: recipe for target `all' failed
make[2]: *** [all] Error 2
make[2]: Leaving directory `/home/Administrator/sage-4.8.alpha3/spkg/build/mpir-2.1.3.p8/src'
Error building MPIR.

real    17m31.973s
user    0m42.992s
sys     1m0.848s
************************************************************************
Error installing package mpir-2.1.3.p8
************************************************************************

Interpreting this error is definitely beyond my pay grade.

[kcrisman]

For reference only - don't build static library

[kcrisman]

The original reported issue is explained best ​at this post. So apparently we can't build both, so what is the best solution?

---

Apparently the ysam problem is a race condition; see ​this post. This would be fixed by mpir upgrading ysam, according to this.

[kcrisman]

MPIR has upgraded this in a release candidate. See ​this mpir-devel post and ​this mpir release.

---

So what should we do about the static library issue? Will this break something if we revert that?

[kcrisman]

I get a different problem on Windows XP on the new MPIR.

../yasm/yasm -I .. -f elf64 -D GSYM_PREFIX lshift.as -DDLL_EXPORT -D PIC -o .libs/lshift.o
/bin/sh ../libtool --mode=compile --tag=CC ../mpn/m4-ccas --m4="m4" gcc -std=gnu99 -c -DHAVE_CONFIG_H    -m32 -O2 -fomit-frame-pointer -mtune=k8 -march=k8   -D__GMP_WITHIN_GMP -I..  -DOPERATION_`echo rshift | sed 's/_$//'` -I. -I..  `test -f 'rshift.asm' || echo './'`rshift.asm
 ../mpn/m4-ccas --m4=m4 gcc -std=gnu99 -c -DHAVE_CONFIG_H -m32 -O2 -fomit-frame-pointer -mtune=k8 -march=k8 -D__GMP_WITHIN_GMP -I.. -DOPERATION_rshift -I. -I.. rshift.asm  -DDLL_EXPORT -DPIC -o .libs/rshift.o
m4  -DHAVE_CONFIG_H -D__GMP_WITHIN_GMP -DOPERATION_rshift -DDLL_EXPORT -DPIC rshift.asm >tmp-rshift.s
 gcc -std=gnu99 -c -DHAVE_CONFIG_H -m32 -O2 -fomit-frame-pointer -mtune=k8 -march=k8 -D__GMP_WITHIN_GMP -I.. -DOPERATION_rshift -I. -I.. tmp-rshift.s -DDLL_EXPORT -DPIC -o .libs/rshift.o
tmp-rshift.s: Assembler messages:
tmp-rshift.s:53: Error: bad register name `%rcx'
tmp-rshift.s:55: Error: bad register name `%rax'
tmp-rshift.s:56: Error: bad register name `%rcx'
tmp-rshift.s:59: Error: bad register name `%rax'
tmp-rshift.s:61: Error: bad register name `%rcx'
tmp-rshift.s:62: Error: bad register name `%rsi,%rdx,8)'
tmp-rshift.s:63: Error: bad register name `%rdi,%rdx,8)'
tmp-rshift.s:64: Error: bad register name `%rdx'
tmp-rshift.s:65: Error: bad register name `%rsi,%rcx,8)'
tmp-rshift.s:70: Error: bad register name `%rax'
tmp-rshift.s:76: Error: bad register name `%rsi,%rcx,8)'
tmp-rshift.s:80: Error: bad register name `%rdi,%rcx,8)'
tmp-rshift.s:82: Error: bad register name `%rsi,%rcx,8)'
tmp-rshift.s:86: Error: bad register name `%rdi,%rcx,8)'
tmp-rshift.s:88: Error: bad register name `%rsi,%rcx,8)'
tmp-rshift.s:92: Error: bad register name `%rsi,%rcx,8)'
tmp-rshift.s:93: Error: bad register name `%rdi,%rcx,8)'
tmp-rshift.s:98: Error: bad register name `%rdi,%rcx,8)'
tmp-rshift.s:100: Error: bad register name `%rcx'
tmp-rshift.s:103: Error: bad register name `%rcx'
tmp-rshift.s:108: Error: bad register name `%rsi,%rcx,8)'
tmp-rshift.s:112: Error: bad register name `%rdi,%rcx,8)'
tmp-rshift.s:114: Error: bad register name `%rsi,%rcx,8)'
tmp-rshift.s:118: Error: bad register name `%rdi,%rcx,8)'
tmp-rshift.s:120: Error: bad register name `%rsi,%rcx,8)'
tmp-rshift.s:124: Error: bad register name `%rdi,%rcx,8)'
tmp-rshift.s:126: Error: bad register name `%rdi,%rcx,8)'
tmp-rshift.s:131: Error: bad register name `%rsi,%rcx,8)'
tmp-rshift.s:135: Error: bad register name `%rdi,%rcx,8)'
tmp-rshift.s:137: Error: bad register name `%rsi,%rcx,8)'
tmp-rshift.s:141: Error: bad register name `%rdi,%rcx,8)'
tmp-rshift.s:143: Error: bad register name `%rdi,%rcx,8)'
tmp-rshift.s:148: Error: bad register name `%rsi,%rcx,8)'
tmp-rshift.s:152: Error: bad register name `%rdi,%rcx,8)'
tmp-rshift.s:154: Error: bad register name `%rdi,%rcx,8)'
tmp-rshift.s:159: Error: bad register name `%rdi,%rcx,8)'
Makefile:605: recipe for target `rshift.lo' failed
make[4]: *** [rshift.lo] Error 1
make[4]: Leaving directory `/home/SageUser/sage-4.8.alpha3/spkg/build/mpir-2.1.3.p8/src/mpn'
Makefile:772: recipe for target `all-recursive' failed
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/home/SageUser/sage-4.8.alpha3/spkg/build/mpir-2.1.3.p8/src'
Makefile:603: recipe for target `all' failed
make[2]: *** [all] Error 2
make[2]: Leaving directory `/home/SageUser/sage-4.8.alpha3/spkg/build/mpir-2.1.3.p8/src'
Error building MPIR.

real    15m36.246s
user    12m36.996s
sys     11m12.666s
************************************************************************
Error installing package mpir-2.1.3.p8
************************************************************************

However, given that this has something to do with yasm, perhaps the new yasm would fix it? Or is this something that would be fixed by rebasing? (I don't see anything about forking, but I don't know how to interpret assembler (!) messages.)

[dimpase]

Replying to kcrisman:

I get a different problem on Windows XP on the new MPIR.

this is a typical assembler error (something to do with the misconfiguration/mismatch of commands for particular hardware). Nothing to do with Cygwin per se. Hopefully can be fixed by yasm upgrade.

[kcrisman]

Any fix here will have to be based on #12139, the new p8.

[kcrisman]

Any fix here will have to be based on #12139, the new p8.

There is now a p9 at #12131.

[jdemeyer]

In the mean time, MPIR has been upgraded again to version 2.4.0, latest spkg is at #12751.

[jpflori]

I get a similar "bad register name" failure with Cygwin 1.17... on Windows 7 64 bits with Sage 5.1.rc1.

[jpflori]

I've get similar errors with the tentative spkg of MPIR 2.5.1 of #13137 (by the way they occur in tmp_mul-1.s as with the standard 5.1.rc1 spkg). What's strange is that I have no problem compiling upstream MPIR 2.5.1...

[jpflori]

Looking at #8664 gave some hints, and checking the log, I see some core2 in mtune and march. Although -m32 is set, maybe some 64 bits stuff... I'm trying again with ABI=32 set.

[jpflori]

Setting ABI=32 solves the problem. I guess the right solution is to define ABI=32 by default on Cygwin as it is only 32 bits for the moment. The day it gets 64 bits, this can be changed.

[jpflori]

Oh and that was with the MPIR 2.5.1 spkg, but I guess trying with the 2.4.0 would give the same result.

[kcrisman]

Thanks for trying things on Cygwin again! I gave up a while ago, but if you can keep build instructions up-to-date at wiki:CygwinPort and #6743, that would be wonderful.

[jdemeyer]

Replying to jpflori:

I get a similar "bad register name" failure with Cygwin 1.17... on Windows 7 64 bits with Sage 5.1.rc1.

Could you please post the mpir-2.4.0.p5.log file?

[jpflori]

Have a look at the 2.4.0.p6 log (the p5 fails because of the static AND shared problem). The 2.5.1.p1 includes several logs (sorry its large) and the first ones should reveal a similar failure. The last log in 2.5.1.p1 was generated with ABI=32 and succeeded.

[jdemeyer]

I understand the problem and it's trivial to fix. Where did you get this mpir-2.4.0.p6 from? There is an mpir-2.4.0.p6 merged in sage-5.2.beta1 (from #12751) but I doubt you're referring to that one.

[jpflori]

I bumped the version number for my experiments.

[jpflori]

Updated spkg based on mpir-2.4.0.p6 available at ​http://perso.telecom-paristech.fr/~flori/sage/mpir-2.4.0.p7.spkg

This chooses to build the shared library only and sets ABI=32 on Cygwin.

[jpflori]

Spkg diff, for review only.

[dimpase]

On my Cygwin, the new spkg hangs on

Checking what CFLAGS MPIR would use if they were empty...

This might have to do with the fact that my 32-bit Win 7 is run in a VMWare VM, rather than being a "real" iron, but this is certainly not good, one way or another.

Any ideas what can be tried to see what's wrong?

EDIT: perhaps I was not patient enough. I tried doing ../../sage -f mpir-2.4.0.p7.spkg and it this part worked OK, although I waited 30 minutes or so.

[jpflori]

Yup, Cygwin is slow and MPIR configure is long. moreover the spkg runs it a first time redirecting its output to some file to get the default flags...

[kcrisman]

This works on Cygwin on XP!

[vbraun]

I would be in favor of never building the static libraries on any system, though we don't have to do that in this ticket. Positive review.

[jpflori]

The spkg at #13137 is based on that one so this ticket should not be merger directly and closed when #13137 is merged.

[jdemeyer]

In general, I think it is a bad idea not to merge a ticket just because another ticket is based on it. Imagine that some major problems arise with #13137, then this ticket here might get lost and forgetten. However, I don't know the specific situation here, so I'll let your decision stand.

[jpflori]

Now it seems that including #13137 will be painful I have to agree with you Jeroen and ask you if it's possible to include this easy fix in 5.6? Sorry for taking the wrong decision in the beginning...

[jdemeyer]

It seems that #13137 is ready after all...