[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Axiom-developer] Re: address@hidden: Re: Installing axiom on suse linux
[Axiom-developer] Re: address@hidden: Re: Installing axiom on suse linux 10.2]
04 Oct 2007 08:52:46 -0400
Gnus/5.09 (Gnus v5.9.0) Emacs/21.2
Turning off si::*default-system-p* as Waldek said works, but does so
by copying the header contents into each .c file to be compiled. One
can also add :system-p nil to the compile-file command. The real
issue is that apparently the install mechanism has not reset the
system library paths to their installed location.
In particular, when you move the compiled source tree (keeping its
structure intact), the si::*system-directory* and si::*lib-directory*
must be set to their final locations. There is a routine
si::reset-sys-paths to help with this:
(defun reset-sys-paths (s)
(declare (string s))
(setq si::*lib-directory* s)
(setq si::*system-directory* (si::string-concatenate s "unixport/"))
(dolist (l '("cmpnew/" "gcl-tk/" "lsp/" "xgcl-2/"))
(push (si::string-concatenate s l) nl))
(setq si::*load-path* nl))
mv foo /new/location/gcl-install/unixport/
GCL's make install is supposed to do this, but if the axiom build is
moving gcl images around by hand, this needs to be invoked at some
Bob Boyer once convinced me that autoloading and other dependence on
runtime files to be found in particular locations was a really bad
idea. One great thing about GCL, IMHO, is that one can use it as a
completely self-contained stand-alone binary which can be moved around
at will (provided at least, of cource, that one sets
si::*default-system-p* to nil).
root <address@hidden> writes:
> GCL seems to have built on Suse 10.2 and the system command works.
> The GCC compiler appears to be in the path. Yet it appears that
> GCL cannot execute it. CC1 seems to be looking in the wrong place
> for the .h files. Do you have any insight into this?
> From: "C. Frangos" <address@hidden>
> Subject: Re: Installing axiom on suse linux 10.2
> To: address@hidden
> Date: Wed, 3 Oct 2007 23:00:10 +0200
> Reply-To: address@hidden
> I tried the instructions and it seems that the )sys command is
> I use this command to delete foo1, and call gcc in order to compile one of my
> C programs located in another directory (see below).
> It seems that gcc is on the path, but I dont recall the linux command to
> explicitly check this.
> C. Frangos.
> (1) -> )sys rm /home/cfrangos/temp/foo1
> (1) -> )sys gcc -o test1 /home/cfrangos/src/agvs1.c -lm -O3
> (1) ->
> >(1) -> )fin
> >BOOT>(defun foo (x) x)
> >BOOT>(compile 'foo)
> >cc1: error: /root/axiom/mnt/fedora5/bin/../h: Permission denied
> >Error: (SYSTEM "gcc -c -Wall -DVOL=volatile -fsigned-char -pipe
> >-I/root/axiom/mnt/fedora5/bin/../h -O3 -fomit-frame-pointer -c
> >\"/tmp/gazonk5.c\" -o \"/tmp/gazonk5.o\" -w") returned a non-zero value 0.
> >Fast links are on: do (si::use-fast-links nil) for debugging
> >Error signalled by UNLESS.
> >Broken at APPLY. Type :H for Help.
> >BOOT>>(foo 3)
> >On Wednesday 03 October 2007 21:49, you wrote:
> >> right. the (foo 3) is interpreted.
> >> the compile step is failing.
> >> somehow axiom (actually gcl) cannot find the gcc command.
> >> is gcc on your path?
> >> or possibly the "system" command does not work.
> >> create a junk file like /tmp/foo by doing "touch /tmp/foo"
> >> start axiom
> >> type
> >> )sys rm /tmp/foo
> >> and see if the file is erased.
> >> If the file is erased then the system command works and
> >> the problem is that gcc cannot be found. If the file is
> >> not erased then the system function is not working and
> >> we have to get Camm (the GCL maintainer) involved.
> >> Tim
Camm Maguire address@hidden
"The earth is but one country, and mankind its citizens." -- Baha'u'llah