[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Axiom-developer] build-improvements on ia64
From: |
Richard Harke |
Subject: |
Re: [Axiom-developer] build-improvements on ia64 |
Date: |
Fri, 10 Nov 2006 10:52:41 -0800 |
User-agent: |
KMail/1.7.2 |
On Thu November 9 2006 12:47, Bill Page wrote:
> If this problem persists after re-building with a fresh copy of
> the Axiom source (see below), it might be a bit hard to diagnose
> with only the information above. :-) My first suggestion is to
> look for the possibility of another error somewhere earlier in
> the build.
>
> Since this looks like the error occurred quite early in the Axiom
> build process, the problem might be a gcl problem so it would
> also probably be worthwhile to double check the log of the gcl
> build. You could try also some simple confidence tests of gcl's
> ability to save a working system such as:
>
> $ gcl
>
> > (+ 1 1)
> > (si::save-system "gcl-test1")
>
> $ ./gcl-test1
>
> > (+ 1 1)
> > (compiler::link nil "gcl-test2")
> > (quit)
>
> $ ./gcl-test2
>
> > (+ 1 1)
> > (quit)
>
> If you get stuck, it might be useful if you could make a copy of
> the console log available for review.
>
>
> I recommend that you do an "out of source" build. This means
> that Axiom is built in a different directory then where the
> source distribution exists.
>
> To do this, first use svn to check-out a clean copy of the
> Axiom source to some directory, e.g. ~/axiom.improvements.
> After that you will not change anything in that directory.
> Instead, create a 2nd directory, e.g.
>
> $ mkdir ~/axiom.build
> $ cd ~/axiom.build
> $ ../axiom.improvements/configure --with-gcl
>
> This will setup the ~/axiom.build directory with just the
> subdirectories and makefiles needed for the build. Then
>
> $ make
>
> builds all of the axiom intermediate files and the final target
> in this 2nd directory.
>
> If the build fails and you want to start entirely from scratch
> then just delete the contents of this directory and issue the
> configure command again:
>
> $ rm -rf *
> $ ../axiom.improvements/configure --with-gcl
>
> Regards,
> Bill Page.
Thanks. This was very helpful. I still have the problem, however.
I agree it appears to be a gcl problem. I didn't see any thing in the
gcl build log and the save-system and compiler::link tests
given above both appeared to work fine. I did try to run this manually:
address@hidden:~/Axiom-svn/build/src/boot$ stage0/bootsys
GCL (GNU Common Lisp) 2.6.8 CLtL1 Nov 9 2006 23:01:51
Source License: LGPL(gcl,gmp), GPL(unexec,bfd,xgcl)
Binary License: GPL due to GPL'ed components: (UNEXEC)
Modifications of this banner must retain notice of a compatible license
Dedicated to the memory of W. Schelter
Use (help) to get some basic information on how to use GCL.
Temporary directory for compiler files set to /tmp/
>(boottran::boottocl "ptyout.boot")
Error: Caught fatal error [memory may be damaged]
Fast links are on: do (si::use-fast-links nil) for debugging
Error signalled by EVAL.
Broken at BOOTTRAN:BOOTTOCL. Type :H for Help.
>>:bt
#0 BOOTTOCL {loc0="ptyout.boot"} [ihs=7]
#1 EVAL {loc0=nil,loc1=nil,loc2=nil,loc3=#<compiled-function
boottran:boottocl>} [ihs=6]
#2 TOP-LEVEL
{loc0=nil,loc1=0,loc2=0,loc3=nil,loc4=nil,loc5=nil,loc6=nil,loc7="/usr/local/lib...}
[ihs=5]
#3 FUNCALL {loc0=#<compiled-function system:top-level>} [ihs=4]
NIL
>>:env
Error: bad env
Fast links are on: do (si::use-fast-links nil) for debugging
Error signalled by LAMBDA-CLOSURE.
Backtrace: system:universal-error-handler > system::break-call > funcall >
funcall > lambda-closure > SYSTEM::DESCRIBE-ENVIRONMENT
Broken at BOOTTRAN:BOOTTOCL.
I did make a feeble attempt to provide more info with :bt and :env
I would like to debug this but my knowledge of lisp is pretty limited.
My knowledge of ia64 is much better.
I also tried to do (si:use-fast-links nil) but that gets segfault
Alos, if I just try gdb stage0/bootsys when I give run, it crashes
(sgfault)
Richard