On 08/11/10 04:43 PM, John H Palmieri wrote:


On Aug 11, 8:24 am, "Dr. David Kirkby"<david.kir...@onetel.net>
wrote:
For the first time today I build a 32-bit version of Sage on OpenSolaris.

This was 4.5.3.alpha0 on my Sun Ultra 27. (I've tried 64-bit OpenSolaris before,
with minimal success, though I can build it). A 64-bit build is just too
unstable, but a 32-bit one is more usable.

I added the following 4 files prior to starting the build:

http://boxen.math.washington.edu/home/kirkby/patches/ecl-10.2.1.p2.spkg
(Seehttp://trac.sagemath.org/sage_trac/ticket/9643)

http://boxen.math.washington.edu/home/kirkby/patches/zn_poly-0.9.p5.spkg
(seehttp://trac.sagemath.org/sage_trac/ticket/9358)

http://boxen.math.washington.edu/home/kirkby/patches/atlas-3.8.3.p14....
Seehttp://trac.sagemath.org/sage_trac/ticket/9508

http://boxen.math.washington.edu/home/kirkby/patches/singular-3.1.0.4...
Seehttp://trac.sagemath.org/sage_trac/ticket/9397

then touched the 4 files.

There were 10 doctest failures - four more than John Palmieri got building
4.5.2.rc1 on 32-bit Solaris 10 on the host fulvia on skynet, which runs Solaris
10 and not OpenSolaris, though both my machine and fulvia have Xeon processors.

I don't know how long the build took, but it was over a hour, as ATLAS has no
tuning parameters for my Xeon W3580 in a 32-bit build. As a 64-bit build, I can
build ATLAS in less than 10 minutes. But 32-bit it takes over an hour.

The following tests failed:

         sage -t  -long devel/sage/doc/en/tutorial/tour_advanced.rst # 2 
doctests failed
         sage -t  -long devel/sage/doc/fr/tutorial/tour_advanced.rst # 2 
doctests failed
         sage -t  -long devel/sage/sage/lfunctions/sympow.py # 13 doctests 
failed
         sage -t  -long devel/sage/sage/modular/hecke/submodule.py # 1 doctests 
failed
         sage -t  -long devel/sage/sage/modular/abvar/abvar.py # 1 doctests 
failed
         sage -t  -long devel/sage/sage/rings/polynomial/groebner_fan.py # 76 
doctests
failed
         sage -t  -long 
devel/sage/sage/schemes/elliptic_curves/ell_rational_field.py #
17 doctests failed
         sage -t  -long 
devel/sage/sage/rings/polynomial/multi_polynomial_ideal.py # 1
doctests failed
         sage -t  -long devel/sage/sage/symbolic/expression.pyx # 2 doctests 
failed
         sage -t  -long devel/sage/sage/stats/hmm/chmm.pyx # 3 doctests failed
----------------------------------------------------------------------
Total time for all tests: 1704.4 seconds

A log of all ptestlong can be found here.

http://boxen.math.washington.edu/home/kirkby/logs/ptestlong-sage-4.5....

So that's some progress now.

To summerise the Solaris builds

   * 32-bit Solaris 10 SPARC - 100% OK
   * 64-bit Solaris 10 SPARC - Can build and work, but very unstable.
   * 32-bit Solaris 10 on x86 - 6 doc tests fail.
   * 32-bit OpenSolaris on x86 - 10 doc tests fail.
   * 64-bit OpenSolaris on x64 - Builds, except R and Maxima, but crashes at
startup. Totally unusable.

Looking at the log, another way to phrase this might be:

   * 32-bit Solaris 10 on x86 - 6 doc tests fail: sympow broken
   * 32-bit OpenSolaris on x86 - 10 doc tests fail: sympow and gfan
broken

(There are also some numerical noise issues, but they not be
important.)

--
John

Yes.

Looking at the source for sympow, I'm not surprised.

I just rebuilt gfan, to check manually that it does build - I know there are some bits of Sage that will appear to install OK, even if they fail, as there is no error checking. But gfan appears to build. I'll look in more detail later.

It looks like it might be a linking problem, as when the doctest is run, the error message is:

RuntimeError: ld.so.1: gfan: fatal: relocation error: file /export/home/drkirkby/32/sage-4.5.3.alpha0/local/bin/gfan: symbol _ZNSt15_List_node_base7_M_hookEPS_: referenced symbol not found

I'll drop the author a note, and ask if he has any ideas. It might be quite easy to fix though. Perhaps adding "-L/$SAGE_LOCAL/lib -R$SAGELOCAL/lib" to the compiler flags might help. Anyway, something to look at. At least this machine is reasonably quick, so debugging is not such a chore as it would be on fulvia or t2.

Dave

--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to 
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org

Reply via email to