autoreconf -I should not have changed the output of config.guess. Something
has gone very wrong.

We supply our own config.guess as the generic one is useless for MPIR

Bill.

On Monday, 3 December 2012, Jean-Pierre Flori wrote:

>
>
> On Monday, December 3, 2012 7:43:38 PM UTC+1, Jean-Pierre Flori wrote:
>>
>>
>>
>> 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 <[email protected] <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> 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.)
>>>
>> I think its a good idea.
> In fact, as I autoreconfed MPIR, now config.guess spits i386... instead of
> nehalem-... before and of course this was not caught by the updated
> configure and I had to craft a new spkg for testing (in which I put
> *-apple-darwin* just to be sure to get everything).
>
>>
>>>
>>> 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'
>>> (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.
>>
>>> -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 view this discussion on the web visit
> https://groups.google.com/d/msg/mpir-devel/-/sIIBdcS7TmcJ.
> To post to this group, send email to 
> [email protected]<javascript:_e({}, 'cvml', 
> '[email protected]');>
> .
> To unsubscribe from this group, send email to
> [email protected] <javascript:_e({}, 'cvml',
> 'mpir-devel%[email protected]');>.
> For more options, visit this group at
> http://groups.google.com/group/mpir-devel?hl=en.
>

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" 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/mpir-devel?hl=en.

Reply via email to