#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 leif):
Replying to [comment:58 jdemeyer]:
> Replying to [comment:53 leif]:
> > > 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.
This doesn't make sense at all. Why do you refuse to use the documented,
supposed (and hence safest) way (or location) to get the flags from? (And
it's in no way more complicated than what you currently do. You could of
course also run the preprocessor on `gmp.h`, but that's IMHO slight
overkill.)
The structure and/or contents of the generated Makefiles is likely to
change with other versions of autotools, probably without intent of the
MPIR developers.
In any case, you should have just changed the
`get_upstream_selected_cflags()` function, instead of removing it.
----
You should also add `-mno-power*` to `get_processor_specific_cflags()`,
since at least a user might use such.
The other changes are reasonable, so I'm ok with the spkg modulo the
useless changes w.r.t. extracting `CFLAGS` (and as already mentioned, I'd
just change the `.asm` files on the fly, not add a large patch which is
under revision control for that*).
Don't know whether we should `cat` the whole `config.log` in case
`configure` failed in the first place; I'd just print its full filename
(and we don't have to "rename" it), like we do in some other spkgs.
[* The "autotools way" would by the way be to check whether m4 bails out
on `define(,1)`, and only if that's the case, modify the offending source
files.]
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/11616#comment:63>
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.
