On 1 July 2010 09:54, François Bissey <f.r.bis...@massey.ac.nz> wrote:
>> I've tried to build a slightly modified version of Sage 4.5.alpha1 on
>> OpenSolaris x64 as a 64-bit application, but have hit two non-trivial
>> issues.
>>
>> * Maxima will not build.
>> * R will not build
>>
>> So I typed
>>
>> $ touch spkg/installed/maxima-$version
>> $ touch spkg/installed/r-$Rversion
>> $ SAGE_PARALLEL_SPKG_BUILD=yes # Parallel build.
>> $ export MAKE="make -j 12"
>> $ make
>>
>> At the end of the build I get:
>>
>> Successfully installed gap-4.4.12.p4
>> Now cleaning up tmp files.
>> rm: Cannot remove any directory in the path of the current working
>> directory /export/home/drkirkby/sage-4.5.alpha1/spkg/build/gap-4.4.12.p4
>> Making Sage/Python scripts relocatable...
>> Making script relocatable
>> 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!
>>
>>
>> Before I cracked open a bottle of Champagne, and started to use Sage for
>> some real work, I thought I better test if Sage actually worked! At which
>> point:
>>
>> 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: 25839
>> Segmentation Fault (core dumped) sage-ipython "$@" -i
>>
>>
>> gdb was not very useful to me. I'm going to update my gdb version before
>> worrying too much about that. I think in fact on Solaris it might be better
>> to use dbx.
>>
>> Anyway, my main point of this is to know whether faking Maxima or R
>> installing could cause this or not. I thought they were not library
>> components, so if they did not exist would not matter one single bit
>> unless one tried to use them. But here Sage wont even start.
>>
> I don't think so. Christopher had a broken maxima yesterday and it still
> started. It is more likely an extension. Can you see if you can run any tests?
> Some stuff may still be able to run.
>
> Francois
>
> --
> 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
>
If you mean by 'make test' then no, I can't get anywhere fast (see
below). I'm going to try a serial build (not building any packages in
parallel). In fact I started that. It should have been finished by
now, but I forgot to touch spkg/installed/maxima-$version and
spkg/installed/r-$version. So needless to say the build failed. I've
just restarted the build. Should be done in 20 minutes or so, but I
don't hold a lot of hope of that fixing it.
The only two things I can think of are
1) Updated gdb and see if that gains me anything, though I doubt it.
2) Delete gdb and make Sun's debugger 'dbx' a link to gdb (A better
longer term solution will be for Sage to take an option to use dbx,
just like it can gdb).
Any other suggestions how one might resolve a segfault on startup?
There are literally thousands of compiler warnings - hard to look over
them to see where the problem might be.
I getter look over the library and see if there are any more
Sun-specific hacks like
http://trac.sagemath.org/sage_trac/ticket/9399
which in fact do more harm than good. I know Micheal that started a
Solaris port worked only on 32-bit, so if he stuck any code which is
valid on 32-bit, but not on 64-bit, it could cause problems. (I've
never built Sage 32-bit on OpenSolaris - decided it was not worth the
bother. But such an attempt might show something useful, as might a
64-bit SPARC build. The main advantage on building on x86 is my
workstation is more than an order of magnitude faster than any SPARC I
have. ).
drkir...@hawk:~/sage-4.5.alpha1$ make test
cd spkg && ./install all 2>&1 | tee -a ../install.log
make[1]: Entering directory `/export/home/drkirkby/sage-4.5.alpha1/spkg'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory `/export/home/drkirkby/sage-4.5.alpha1/spkg'
real 0m0.139s
user 0m0.004s
sys 0m0.004s
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!
./sage -docbuild all html 2>&1 | tee -a dochtml.log
sphinx-build -b html -d
/export/home/drkirkby/sage-4.5.alpha1/devel/sage/doc/output/doctrees/en/a_tour_of_sage
/export/home/drkirkby/sage-4.5.alpha1/devel/sage/doc/en/a_tour_of_sage
/export/home/drkirkby/sage-4.5.alpha1/devel/sage/doc/output/html/en/a_tour_of_sage
------------------------------------------------------------
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).
------------------------------------------------------------
--
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
