On 1 July 2010 02:43, François Bissey <f.r.bis...@massey.ac.nz> wrote:
>> It would be really good to get this patch into Sage asap, as it allows one
>> to build a very large part of the Sage library on OpenSolaris.
>>
>> All it does, is adds these 4 lines a SCons configuration file
>>
>>
>> if env['PLATFORM'] != "darwin" and os.environ['SAGE64']=="yes":
>> env.Append( CFLAGS="-O2 -g -m64" )
>> env.Append( CXXFLAGS="-O2 -g -m64" )
>> env.Append( LINKFLAGS="-m64" )
>>
>>
>>
>> which adds the all important -m64 flag if SAGE64 is set to "yes" and the
>> operating system is *not* OS X. The SAGE64 variable is used on OS X in
>> another part of the script, but some other obscure flags are added, which
>> I don't want to add on Solaris.
>>
>> http://trac.sagemath.org/sage_trac/ticket/9097
>>
>> It should be fairly obvious that this fix is very low risk, as it only has
>> an effect if one uses SAGE64 on some operating system other than OS X, and
>> so far it is only ever been used on OS X.
>>
> Hi Dave,
>
> I posted my take on it on trac. I will have a quick look at the building of
> extension. I think you are out of the woods for sage_clib but the extensions
> are another matter.
>
> Francois
Hi,
I thought the original patch was smaller, and less likely to cause a
reviewer concerns, as it was obvious it would have no effect on
another platform.
I was hoping it might get in on 4.5 - depends on Robert's
interpretation of Library and script. I know he has closed merging
.spkg files.
I must admit, I can't follow your patch - one obvious thing is that it
would appear to print "MacIntel in 64 bit mode" whenever SAGE64 is set
to yes. I've not actually applied your version. I'm actually sitting
in bed now, and have given up coding today. So I will investigate
tomorrow.
There's a bit of annoying Sun-specific code in one of the Sage header
files (sage/rings/finite_rings/stdint.h). After I removed that, the
whole of Sage library built ok. In fact, Sage claims to have bult,
though I had faked Maxma and R by touching the required file in
spkg/installed.
As you can see below, the build took 39 minutes 25 seconds.
Finished installing gap-4.4.12.p4.spkg
make[1]: Leaving directory `/export/home/drkirkby/sage-4.5.alpha1/spkg'
real 39m25.766s
user 91m39.071s
sys 12m12.928s
To install gap, gp, singular, etc., scripts
in a standard bin directory, start sage and
type something like
sage: install_scripts('/usr/local/bin')
at the Sage command prompt.
To build the documentation, run
make doc
Sage build/upgrade complete!
drkir...@hawk:~/sage-4.5.alpha1$ ./sage
----------------------------------------------------------------------
| Sage Version 4.5.alpha1, Release Date: 2010-06-29 |
| Type notebook() for the GUI, and license() for information. |
----------------------------------------------------------------------
**********************************************************************
* *
* Warning: this is a prerelease version, and it may be unstable. *
* *
**********************************************************************
------------------------------------------------------------
Unhandled SIGSEGV: A segmentation fault occurred in Sage.
This probably occurred because a *compiled* component
of Sage has a bug in it (typically accessing invalid memory)
or is not properly wrapped with _sig_on, _sig_off.
You might want to run Sage under gdb with 'sage -gdb' to debug this.
Sage will now terminate (sorry).
------------------------------------------------------------
/export/home/drkirkby/sage-4.5.alpha1/local/bin/sage-sage: line 206:
29004 Segmentation Fault (core dumped) sage-ipython "$@" -i
drkir...@hawk:~/sage-4.5.alpha1$
So Sage bas built, but there is cleanly a problem. I wonder if this
could be because R and Maxima have not actually built?
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
