Michael, I interrupted the sage build during the construction of gmp, went to the spkg/build/gmp-4.2.2/src directory and diff-ed the configure file against the configure file that I obtained from a direct download of gmp-4.2.2
I discovered that while the gmp spkg claims to be 4.2.2, the configure script is from gmp-4.2.1 and is missing a number of items that relate to the definition of the ABI environment variable, particularly for x86_64 systems. Could it be that someone inadvertently packaged gmp-4.2.1? I saw in an earlier post from WIlliam Stein that the spkg is just a compressed tar file, but when I looked at the directory structure of the gmp-4.4.2 from the sage-3.0.3 package, it had some added directories (e.g., patch) and the src directory seemed to contain the libgmp-4.2.2 contents. Can I try to build my own spkg for gmp-4.2.2? The initialization problem seems to be coming from an assert inside some libgmp code, so the problem may end up just being with libgmp. If there are any headers from libgmp that were used in the build of subsequent sage objects, that might explain the abort that I see when sage initializes. I'll give sage-3.0.4.alpha1 a go and see what happens. And I'll also try to build my own gmp-4.2.2 spkg and see how that goes. John Bussoletti On Jun 24, 5:51 am, mabshoff <[EMAIL PROTECTED] dortmund.de> wrote: > 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- Hide quoted text - > > - Show quoted text -- Hide quoted text - > > - Show quoted text - --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-support@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---
