#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:48 leif]:
> It would have been better if you made a p3, and not deleted my diff with
the changes of my p2.
Since your changes weren't committed, I thought it was open to changes.
Anyway, this would probably "blow up" the Mercurial repository more than
my .asm patch ;-)
> There's no need to remove the conditional unsetting of `PYTHON`, as I
already argued above.
I really don't see the need for the `PYTHON` stuff. If somebody just
installs this spkg with "`./sage -i`", then `PYTHON` will not be set.
`PYTHON` will only be set if this spkg is installed through
`spkg/install`. I cannot think of a plausable scenario where this would
happen.
> 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
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.
> Reading `CC` and `CFLAGS` ''from system-wide `gmp.h` files'' is also
for informational purposes.
Who reads log files anyway?
> 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.)
Agreed that it's subject to change without notice, but at least we'll
notice if it changes. Reading them from Makefile is absolutely the
easiest way.
> You should also check whether reading the `CFLAGS` from the `Makefile`
apparently succeeded.
This is harder to do. In theory, `CFLAGS` could be empty. Moreover, it
looks quite unlikely to me that reading `CC` would succeed but reading
`CFLAGS` would fail.
> I don't know why you removed the `-march=native` stuff;
I removed it because it wasn't used! Reading the CC and CFLAGS from MPIR
should always succeed now (as far as I can tell), so the code using
`-march=native` would never be reached.
> 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.
Perhaps always using `-march=native` does make sense, but that's outside
the scope of this ticket.
> 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.
So what? Why ''a priori'' restrict it to Linux?
> Moreover, using the odd `testcc.sh` script fails if `$CC` contains more
than one word
Agreed, `$CC` should be quoted.
> using shell pattern matching is not only more efficient
Seriously? You're worrying about efficientcy of shell scripts?
> but also more readable.
I find my code quite 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.
Let's see what users report... It doesn't make sense to me to add a
complicated workaround for a corner case which doesn't occur in practice.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/11616#comment:51>
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.
