Am 03.12.2012 19:43, schrieb Jean-Pierre Flori:
On Monday, December 3, 2012 7:20:45 PM UTC+1, leif wrote:
Jean-Pierre Flori wrote:
> On Monday, December 3, 2012 6:35:15 PM UTC+1, Bill Hart wrote:
>
> Time to apply the crumb test to JP's beard with a
fine-toothed comb!
>
> By the way, shouldn't Sage be a little faster on my Amstrad
PC1512?
>
> Bill.
>
> On 3 December 2012 17:29, leif <not.r...@online.de
<javascript:>>
> wrote:
> > Jean-Pierre Flori wrote:
> >>
> >>
> >>
> >> On Monday, December 3, 2012 6:13:57 PM UTC+1, leif wrote:
> >>
> >> Jean-Pierre Flori wrote:
> >> > Further info:
> >> > - the result of ./config.guess is
nehalem-apple-darwin9.8.0,
> >> which is
> >> > not one dealt with in MPIR configure.in
<http://configure.in>
> <http://configure.in> <http://configure.in> for
> >>
> >> the "32 bit apple darwin
> >> > doesn't like our PIC format asm code".
> >> > - and so we get MPN_PATH=" x86/nehalem x86 generic"
> >>
> >> ... then the -march=core-i7 was pretty correct.
> >>
> >> Who t** f*** runs a 32-bit operating system on such a
> machine? (Dual
> >> quad-core Xeon even IIRC) ;-)
> >>
> >> I agree :)
> >> And that's the reason nobody complained until we
explicitely pushed
> >> people to do so :)
> >
> >
> > Well, YOU asked for it, so it's definitely your fault... ;-)
> >
> >
> >
> > -leif
>
> In fact I just wanted to get rid of the dirty piece of code in
sage spkg
> install script and hoped that nobody would actually answer on
sage-devel
> so that the removal gets undetected.
How about changing
# 32bit apple darwin doesn't like our PIC format asm code
case $host in
core2-apple-darwin* | penryn-apple-darwin*)
path="x86/applenopic/core2 x86/applenopic" ;;
prescott-apple-darwin* | pentium4-apple-darwin*)
path="x86/applenopic" ;;
pentium3-apple-darwin* | pentium2-apple-darwin*)
path="x86/applenopic" ;;
i686-apple-darwin* | pentiumpro-apple-darwin*)
path="x86/applenopic" ;;
core-apple-darwin*)
path="x86/applenopic" ;;
*) ;;
esac
to just
# 32bit apple darwin doesn't like our PIC format asm code
case $host in
core2-apple-darwin* | penryn-apple-darwin*)
path="x86/applenopic/core2 x86/applenopic" ;;
*-apple-darwin*)
path="x86/applenopic" ;;
*) ;;
esac
? (As far as I can see, the above snippet is in the x86/x86_64 (and
32-bit OS/ABI) branch, so we don't have to deal with other archs than
these there.)
Otherwise the build will (sooner or later) fail in exactly the same way
on newer CPUs on 32-bit Darwin.
Btw, it would probably be better to use the applenopic/core2 path on
any
post-Core2 CPU as well. Then we'd have to invert the logic, such that
the x86/applenopic/core2 path is *not* chosen / added on
i[34567]86-|pentium*-|prescott-|core- (all with 'apple-darwin*'
appended), but on everything else, hoping that the former list is
complete. (We won't have to add CPUs to that list as time goes by, in
contrast to the post-Core2 list.)
For the sake of Sage, it's probably better to patch MPIR 2.6.0's
'configure' (i.e., the *generated* file) rather than 'configure.in
<http://configure.in>'
(autoreconfing afterwards, which usually causes lots of file changes)
until 2.6.1 (with such a fix) is out.
It should be ok thanks to Jeroen spkg which choose the same version
autotools as the one used, so producing minimal diffs.
Well, in general even small changes to the autoconf source files can
result in huge diffs for the generated files, no matter whether you're
using the exact same versions of autotools (including libtool) or not.
But if that's not the case here, I won't object patching the whole
source tree in 'spkg-install'.
-leif
--
() The ASCII Ribbon Campaign
/\ Help Cure HTML E-Mail
--
You received this message because you are subscribed to the Google Groups
"mpir-devel" group.
To post to this group, send email to mpir-devel@googlegroups.com.
To unsubscribe from this group, send email to
mpir-devel+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/mpir-devel?hl=en.
