Opened 9 years ago
Closed 8 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 )
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)
Change History (42)
comment:1 Changed 9 years ago by
- Summary changed from MPIR won't build on Cygwin due to building static library to New MPIR won't build on Cygwin
comment:2 Changed 9 years ago by
- 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 9 years ago by
- 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: ↓ 5 Changed 9 years ago by
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 9 years ago by
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: ↓ 7 Changed 9 years ago by
Any fix here will have to be based on #12139, the new p8.
comment:7 in reply to: ↑ 6 Changed 9 years ago by
comment:8 Changed 9 years ago by
In the mean time, MPIR has been upgraded again to version 2.4.0, latest spkg is at #12751.
comment:9 follow-up: ↓ 15 Changed 9 years ago by
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 9 years ago by
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 9 years ago by
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 9 years ago by
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 9 years ago by
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 9 years ago by
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 9 years ago by
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 9 years ago by
Changed 9 years ago by
Changed 9 years ago by
comment:16 Changed 9 years ago by
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 9 years ago by
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 9 years ago by
I bumped the version number for my experiments.
comment:19 Changed 9 years ago by
- 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.
comment:20 Changed 9 years ago by
- 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.
comment:21 Changed 9 years ago by
- Status changed from needs_work to needs_review
comment:22 Changed 9 years ago by
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 9 years ago by
- Keywords spkg added
comment:24 Changed 8 years ago by
- Description modified (diff)
comment:25 Changed 8 years ago by
This works on Cygwin on XP!
comment:26 Changed 8 years ago by
- 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 8 years ago by
- Description modified (diff)
comment:28 Changed 8 years ago by
- Description modified (diff)
comment:29 follow-up: ↓ 31 Changed 8 years ago by
comment:30 Changed 8 years ago by
- Description modified (diff)
comment:31 in reply to: ↑ 29 Changed 8 years ago by
- 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 8 years ago by
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 8 years ago by
- Dependencies set to #13137
comment:34 Changed 8 years ago by
- 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 8 years ago by
- Cc jdemeyer added
comment:36 Changed 8 years ago by
- Milestone changed from sage-5.6 to sage-5.7
comment:37 Changed 8 years ago by
- 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...
I fixed this with a jury-rigged spkg here. Patch attached, just for reference.
Next error:
Interpreting this error is definitely beyond my pay grade.