#11616: Upgrade MPIR to a more recent upstream release
----------------------------------------------------------------------------------------------------------------+
Reporter: leif
| Owner: leif
Type: enhancement
| Status: needs_review
Priority: blocker
| Milestone: sage-5.0
Component: packages
| Resolution:
Keywords: sd32, GMP, SandyBridge, Westmere, yasm re2c race condition,
Linux ia64 Itanium GCC 4.7.0 bug | Work issues:
Report Upstream: N/A
| Reviewers: Jeroen Demeyer, Leif Leonhardy
Authors: Leif Leonhardy, Jeroen Demeyer
| Merged in:
Dependencies:
| Stopgaps:
----------------------------------------------------------------------------------------------------------------+
Comment (by jdemeyer):
Replying to [comment:53 leif]:
> If one makes changes to other people's code, one should always make a
diff; that's what reviewer patches are for. I also wanted to make further
changes. Apart from that, it's confusing to have different spkgs with the
same patch level at different locations.
Agreed, that's fixed now.
> XD Just follow the instructions given in this ticket's description (and
elsewhere):
I fixed your instructions.
> > The patch isn't that large, so it's not going to "blow up" the
Mercurial repository. Besides, I don't want to worry about the
portability of the find/sed commands that I'm using.
>
> :-) Elsewhere we do...
Again: since I'm not sure how to do it in a portable way, I prefer to be
safe and not do it.
> > Reading them from Makefile is absolutely the easiest way.
>
> Is it? You use almost the same `sed` commands. And it's more error-
prone; just imagine we have
> {{{
> #!make
> CFLAGS = -foo -bar # This is a comment.
> }}}
> Then `mpir_cflags` would certainly not be empty, but ... (Likewise for
`CC`.) Even the usage of one or more tabs can break your code.
This is all true, but the point is that MPIR (actually, automake) doesn't
put those comments, nor do they use TABs. We cannot predict how
`Makefile` will look like in the future, but we also cannot predict how
`gmp.h` or `mpir.h` will look like in the future. I think it is very
unlikely that a future MPIR will break my script in a way that nobody
notices.
> Is it? But removing the code ''is'' in its scope?
The removed code wasn't used. Feel free to make a new MPIR spkg to re-
enable `-march=native`. Even better: fix the upstream code to add
`march=native` if supported.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/11616#comment:58>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sage-trac?hl=en.
