Minh Nguyen wrote:
Hi David,
On Thu, Jan 28, 2010 at 10:05 PM, Dr. David Kirkby
<[email protected]> wrote:
<SNIP>
That will not work. I tried to build Sage 4.3.1.alpha1 and it failed on my
home machine. I think sage 4.3 with
http://trac.sagemath.org/sage_trac/ticket/8088
Do you mean ticket #6595?
http://trac.sagemath.org/sage_trac/ticket/6595
Yes, sorry, that is correct.
Here's another version:
http://sage.math.washington.edu/home/mvngu/sage-src/sage-4.3.0.1.tar
It's based on Sage 4.3 with the patch at #6595.
That should do it. I am just in the process of downloading this, although I
estime it will take another 50 minutes. I will then try to build on my Blade
2000. I'm 99% sure that will build ok, even with the Sun compilers present.
Assuming that works, if it can be put on the Sage web site, I will put an
announcement on comp.unix.solaris, and hopefully get some more people
interested. I know a few people at Sun in the UK are keen to try this. I am
going to give a talk about Sage LOSUG (London Open Solaris User Group) in April.
Here's an email I got from someone at Sun UK.
***********From James MacFarlane at Sun dot com ****************
Hi Dave,
I like the topic - it's free & open source, integrates onto Solaris and the
OpenSolaris port is something that can be discussed even if it's not already
happened.
On top of that it's different to me picking someting new in OpenSolaris and
helps broaden the subjects we cover. I already showed the website to one of our
colleagues who's waiting to go play with it now
*****************************************************************
To help narrow down where a build on t2.math would fail, I'm dividing
various tickets closed in Sage 4.3.1.alpha1 into 9 batches:
* sage-4.3.0.1.alpha0: #6425, #6772, #7799, #7775, #7772
That is really helpful.
The order of the tickets is the order in which I think their
corresponding patches were merged in Sage 4.3.1.alpha1, except for the
tickets with spkg updates/upgrades. I can't work out precisely when
those tickets with spkg updates/upgrades were merged. For example, if
ticket T1 only has patch(es) for the Sage library and ticket T2 has an
updated spkg, was the patches in T1 merged before or after the spkg in
T2?
Understood.
Now back to the 9 batches of tickets above. Starting from Sage 4.3,
one could produce, say, 9 releases with patches on top of it. For
example, Sage 4.3.0.1.alpha0 would contain patches from the listed
tickets. Sage 4.3.0.1.alpha1 would be based on Sage 4.3.0.1.alpha0
with patches from the listed tickets. And so on. One then builds each
alpha release on t2.math and see which one fails. I admit this is
tedious, especially the process of applying patches. But it's one way
to find out which alpha release and hence which batch of tickets
results in a build failure on t2.math. I'm implementing this plan and
will report results in a day or two. (Building Sage on t2.math takes
about a day.)
I'll try this on my Blade 2000. That is faster than 't2' though of course 't2'
could have many builds run in parallel, whereas my Blade 2000 has only 2 CPUs -
and each CPU has only one core. This machine was made in 2002 - I think that was
before the days of multi-core CPUs.
With all the recent patches for Open Solaris x64 from myself and Jaap Spies
(mainly Jaap in fact - I have a job keeping up reviewing them!), a 64-bit SPARC
port might not be too far off. The main issue preventing 64-bit builds on either
platform is the number of packages which were configured to build 64-bit with
if [ `unname` = Darwin -a $SAGE64 = yes ] ; then
CFLAGS = "$CFLAGS -m64"
fi
I've fixed countless numbers of them in the past, but there are still more to
do. Jaap has done quite a few.
There are still a few issues though - zlib is one problem, as convincing that to
build a 64-bit shared library seems difficult.
Dave
--
To post to this group, send an email to [email protected]
To unsubscribe from this group, send an email to
[email protected]
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
