Opened 8 years ago

Closed 7 years ago

#12115 closed defect (duplicate)

New MPIR won't build on Cygwin

Reported by: kcrisman Owned by: tbd
Priority: major Milestone: sage-duplicate/invalid/wontfix
Component: porting: Cygwin Keywords: mpir cygwin spkg
Cc: leif, dimpase, wbhart, jdemeyer Merged in:
Authors: Reviewers: Volker Braun, Karl-Dieter Crisman, Jean-Pierre Flori
Report Upstream: None of the above - read trac for reasoning. Work issues:
Branch: Commit:
Dependencies: Stopgaps:

Description (last modified by jpflori)

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.

Attachments (5)

draft-of-diff-mpir-2.1.3.p7-p8.diff (1.1 KB) - added by kcrisman 8 years ago.
For reference only - don't build static library
mpir-2.4.0.p5.log (9.7 KB) - added by jpflori 7 years ago.
mpir-2.5.1.p1.log (539.9 KB) - added by jpflori 7 years ago.
mpir-2.4.0.p6.log (152.3 KB) - added by jpflori 7 years ago.
spkg.diff (2.2 KB) - added by jpflori 7 years ago.
Spkg diff, for review only.

Download all attachments as: .zip

Change History (42)

comment:1 Changed 8 years ago by kcrisman

  • Summary changed from MPIR won't build on Cygwin due to building static library to New MPIR won't build on Cygwin

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.

Changed 8 years ago by kcrisman

For reference only - don't build static library

comment:2 Changed 8 years ago by kcrisman

  • Report Upstream changed from N/A to None of the above - read trac for reasoning.

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.

comment:3 Changed 8 years ago by kcrisman

  • Report Upstream changed from None of the above - read trac for reasoning. to Fixed upstream, in a later stable release.

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?

comment:4 follow-up: Changed 8 years ago by 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.)

comment:5 in reply to: ↑ 4 Changed 8 years ago by 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.

comment:6 follow-up: Changed 8 years ago by kcrisman

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

comment:7 in reply to: ↑ 6 Changed 8 years ago by kcrisman

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

There is now a p9 at #12131.

comment:8 Changed 8 years ago by jdemeyer

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

comment:9 follow-up: Changed 7 years ago by jpflori

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

comment:10 Changed 7 years ago by 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...

comment:11 Changed 7 years ago by 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.

comment:12 Changed 7 years ago by 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.

comment:13 Changed 7 years ago by 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.

comment:14 Changed 7 years ago by 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.

comment:15 in reply to: ↑ 9 Changed 7 years ago by 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?

Changed 7 years ago by jpflori

Changed 7 years ago by jpflori

Changed 7 years ago by jpflori

comment:16 Changed 7 years ago by 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.

comment:17 Changed 7 years ago by 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.

comment:18 Changed 7 years ago by jpflori

I bumped the version number for my experiments.

comment:19 Changed 7 years ago by jpflori

  • Authors set to Karl-Dieter Crisman, Jean-Pierre Flori
  • Description modified (diff)
  • Keywords mpir cygwin added
  • Report Upstream changed from Fixed upstream, in a later stable release. to None of the above - read trac for reasoning.
  • Status changed from new to needs_review

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.

Changed 7 years ago by jpflori

Spkg diff, for review only.

comment:20 Changed 7 years ago by dimpase

  • Status changed from needs_review to needs_work

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.

Last edited 7 years ago by dimpase (previous) (diff)

comment:21 Changed 7 years ago by dimpase

  • Status changed from needs_work to needs_review

comment:22 Changed 7 years ago by 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...

comment:23 Changed 7 years ago by jpflori

  • Keywords spkg added

comment:24 Changed 7 years ago by jpflori

  • Description modified (diff)

comment:25 Changed 7 years ago by kcrisman

This works on Cygwin on XP!

comment:26 Changed 7 years ago by vbraun

  • Reviewers set to Volker Braun
  • Status changed from needs_review to positive_review

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.

comment:27 Changed 7 years ago by jpflori

  • Description modified (diff)

comment:28 Changed 7 years ago by jpflori

  • Description modified (diff)

comment:29 follow-up: Changed 7 years ago by jpflori

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

comment:30 Changed 7 years ago by jpflori

  • Description modified (diff)

comment:31 in reply to: ↑ 29 Changed 7 years ago by jdemeyer

  • Authors Karl-Dieter Crisman, Jean-Pierre Flori deleted
  • Milestone changed from sage-5.6 to sage-duplicate/invalid/wontfix
  • Reviewers changed from Volker Braun to Volker Braun, Karl-Dieter Crisman, Jean-Pierre Flori

comment:32 Changed 7 years ago by 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.

comment:33 Changed 7 years ago by jdemeyer

  • Dependencies set to #13137

comment:34 Changed 7 years ago by jpflori

  • Authors set to Karl-Dieter Crisman, Jean-Pierre Flori
  • Dependencies #13137 deleted
  • Milestone changed from sage-duplicate/invalid/wontfix to sage-5.6

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...

comment:35 Changed 7 years ago by jpflori

  • Cc jdemeyer added

comment:36 Changed 7 years ago by jdemeyer

  • Milestone changed from sage-5.6 to sage-5.7

comment:37 Changed 7 years ago by jdemeyer

  • Authors Karl-Dieter Crisman, Jean-Pierre Flori deleted
  • Milestone changed from sage-5.7 to sage-duplicate/invalid/wontfix
  • Resolution set to duplicate
  • Status changed from positive_review to closed

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

Note: See TracTickets for help on using tickets.