On Jun 23, 11:08 pm, JohnBussoletti <[EMAIL PROTECTED]>
wrote:
> > Can you post the output for at least one CPU from /proc/cpuinfo?

Hi John,

> Okay, here's the output of cat /proc/cpuinfo:
>
> processor       : 0
> vendor_id       : GenuineIntel
> cpu family      : 15
> model           : 6
> model name      :                   Intel(R) Xeon(TM) CPU 3.20GHz
> stepping        : 4
> cpu MHz         : 3192.009
> cache size      : 2048 KB
> physical id     : 0
> siblings        : 2
> core id         : 0
> cpu cores       : 2
> fpu             : yes
> fpu_exception   : yes
> cpuid level     : 6
> wp              : yes
> flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca 
> cmov
> pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall lm pni
> monitor ds_cpl cid cx16 xtpr lahf_lm
> bogomips        : 6388.99
> clflush size    : 64
> cache_alignment : 128
> address sizes   : 36 bits physical, 48 bits virtual
> power management:

This is in line with my expectations and will very, very likely be
fixed in Sage 3.0.4.

> > We have had three similar build reports and will be switching to a
> > fork of GMP in the near future. We have fixes for many of the
> > misdetection issues with the latest Core2 and Xeon CPUs and those will
> > be in the next Sage release.
>
> > The above points to gmp itself, so can you build and compile a vanilla
> > gmp 4.2.2 from sources and run make check and also verify that the
> > output is truly a 64 bit library. It is very likely that you have a 64
> > bit gmp library on your system and some other component might have
> > picked up a 32 bit gmp from the Sage build.
>
> Yes, the system has an earlier release of libgmp, but there were some
> changes in calling routines or some new links into the library with
> the new version.  I did build the 64 bit version, tested it and
> verified that it was a 64 bit version of the library, and, having done
> so, the "make" process of sage completed successfully.  However, the
> first execution of sage resulted in the error message noted above:
>
>  ./sage
> ----------------------------------------------------------------------
> | SAGE Version 3.0.3, Release Date: 2008-06-17
> |
> | Type notebook() for the GUI, and license() for information.
> |
> ----------------------------------------------------------------------
>
> init2.c:37:  assertion failed: ((32 - 0)+0) == (((32 - 0)+0)/8) * 8
> &&
> sizeof(mp_limb_t) == (((32 - 0)+0)/8)
> /acct/jeb9140/sage/sage-3.0.3/local/bin/sage-sage: line 214: 10096
> Segmentation fault      (core dumped) sage-ipython "$@" -c
> "$SAGE_STARTUP_COMMAND;"
>
> which looks like potentially another instance of a 32 bit versus 64
> bit inconsistency.  That is, I'm speculating that the "32" in the
> assertion has been construced from a DEFINE that mistakenly identified
> the system as a 32 bit system and the sizeof(mp_limb_t) yields "64".
> So even with a correct 64 bit build of libgmp*, and a "correct" build
> of sage, the system failed to initialized correctly.

Ok. Sage 3.0.4.alpha1 released today should contain a fix to build gmp
on CPUs like your in 64 bit mode again, so it would be great if you
could test that. I need to take a look at install.log if you still
have a problem since it sounds likely that some other configure script
would end up misidentifying the CPU again.

> John Bussoletti

Cheers,

Michael
--~--~---------~--~----~------------~-------~--~----~
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-support
URLs: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---

Reply via email to