[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 ~/
>   $ cd ~/
>   $ ../axiom.improvements/configure --with-gcl
> This will setup the ~/ 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.

#0   BOOTTOCL {loc0="ptyout.boot"} [ihs=7]
#1   EVAL {loc0=nil,loc1=nil,loc2=nil,loc3=#<compiled-function 
boottran:boottocl>} [ihs=6]
#3   FUNCALL {loc0=#<compiled-function system:top-level>} [ihs=4]

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


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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]