#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:
----------------------------------------------------------------------------------------------------------------+
Changes (by leif):
* reviewer: Jeroen Demeyer => Jeroen Demeyer, Leif Leonhardy
Comment:
It would have been better if you made a p3, and not deleted my diff with
the changes of my p2.
I agree with some, but not all of your changes:
* There's no need to remove the conditional unsetting of `PYTHON`, as I
already argued above.
* I wouldn't add a patch for the `.asm` files, but instead "patch" them
(with `sed`) on the fly. Otherwise this just blows up the Mercurial
repository, and hopefully upstream will fix this in the next release.
(MPIR 2.5.2 was originally scheduled for about one or two weeks ago.)
* Reading `CC` and `CFLAGS` ''from system-wide `gmp.h` files'' is also
for informational purposes. Using the strings from that header (and not
MPIR's `Makefile`, which btw. could contain tabs as well) is the safer
way, as these definitions are documented and '''supposed''' to be (easily
read out and) used by other programs. (The [structure of the] `Makefile`
is subject to change without notice.)
You should also check whether reading the `CFLAGS` from the `Makefile`
apparently succeeded.
* I don't know why you removed the `-march=native` stuff; I does in
general make sense, especially since (at least the version in Sage -- also
regarding how long it takes to get a "new" version in) will not always
properly detect the CPU, i.e., will choose a more generic target CPU
[family] than `-march=native` does.
* It's not necessary to move the work-around for GCC 4.7.x on ia64, as we
don't support Itanium on anything but Linux. Moreover, using the odd
`testcc.sh` script fails if `$CC` contains more than one word, and using
shell pattern matching is not only more efficient but also more readable.
* I'm pretty sure we still need a work-around for newer CPUs (and GCCs)
on MacOS X, slightly different to what I previously added to the p2, at
least to avoid strange error messages.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/11616#comment:48>
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.
