axiom-developer
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Axiom-developer] problems compiling wh-sandbox 503


From: Waldek Hebisch
Subject: Re: [Axiom-developer] problems compiling wh-sandbox 503
Date: Thu, 12 Apr 2007 13:49:02 +0200 (CEST)

Martin Rubey wrote:
> Dear Waldek,
> 
> unfortunately I have yet again trouble compiling. This time on a collegues
> machine, ubuntu 7.04
> 
> we downloaded a pre-packaged gcl, since the gcl from build improvements didn't
> build either...
> 
> cd ax-build
> ../wh-sandbox/configure 
> 
> works fine, but
> 
> LANG=C make
> 
> says:
> 
> 
> cd ./src && SPAD=/home/harre/ax-build/target/i686-pc-linux SRC=/src
> INT=/home/harre/ax-build/int OBJ=/home/harre/ax-build/obj
> INC=/home/harre/ax-build/../wh-sandbox/src/include NOISE="-o
> /home/harre/ax-build/build/i686-pc-linux/trace" VERSION="Axiom wh-sandbox
> branch 2006-03-28" DOCUMENT=/home/harre/ax-build/build/scripts/document PLF=""
> CCF="-O2 -fno-strength-reduce -Wall -D_GNU_SOURCE" LDF="-g" LISP=lsp make
> make[1]: Entering directory `/home/harre/ax-build/src'
> make[2]: Entering directory `/home/harre/ax-build/src/lib'
> make[2]: Nothing to be done for `all'.
> make[2]: Leaving directory `/home/harre/ax-build/src/lib'
> cd lisp &&  make all-lisp
> make[2]: Entering directory `/home/harre/ax-build/src/lisp'
> echo '(compiler::link nil "/home/harre/ax-build/build/i686-pc-linux/bin/lisp" 
> '
> \
>               ' (format nil "(progn (let ((*load-path* (cons ~S 
> *load-path*))'\
>                                         ' (si::*load-types* ~S))' \
>                                        ' (compiler::emit-fn t))' \
>                                   ' (when (fboundp (quote si::sgc-on))' \
>                                         ' (si::sgc-on t))' \
>                                   ' (setq compiler::*default-system-p* t))"' \
>                       ' si::*system-directory* (quote (list ".lsp")))' \
>                '  "/home/harre/ax-build/src/lib/bsdsignal.o
> /home/harre/ax-build/src/lib/cfuns-c.o
> /home/harre/ax-build/src/lib/sockio-c.o")' \
>             | /usr/bin/gcl
> GCL (GNU Common Lisp)  2.6.7 CLtL1    Nov  9 2006 17:51:02
> Source License: LGPL(gcl,gmp), GPL(unexec,bfd,xgcl)
> Binary License:  GPL due to GPL'ed components: (XGCL READLINE BFD 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/
> 
> >/usr/bin/ld: cannot find -lXmu
> collect2: ld returned 1 exit status
> sh: /home/harre/ax-build/build/i686-pc-linux/bin/raw_lisp: not found
> 
> Error: Cannot delete the file 
> #p"/home/harre/ax-build/build/i686-pc-linux/bin/raw_lisp": "No such file or 
> directory".
> Fast links are on: do (si::use-fast-links nil) for debugging
> Error signalled by LET*.
> Broken at DELETE-FILE.  Type :H for Help.
> >>make[2]: *** [/home/harre/ax-build/build/i686-pc-linux/bin/lisp] Error 255
> make[2]: Leaving directory `/home/harre/ax-build/src/lisp'
> make[1]: *** [all-lisp] Error 2
> make[1]: Leaving directory `/home/harre/ax-build/src'
> make: *** [all-src] Error 2
> 
> 

As Gregory Vanuxem the problem appeared because gcl (more precisely
compiler::link) requires _developement_ versions of X libraries,
but the system contains only normal versions.

I would say that this is a bug in Ubutu gcl package.  AFAICS in
may version of Debian gcl description reads:

Package: gcl
Priority: optional
Section: interpreters
Installed-Size: 160052
Maintainer: Camm Maguire <address@hidden>
Architecture: amd64
Version: 2.6.7-32
Depends: libc6 (>= 2.3.5-1), libgmp3c2, libice6 (>= 1:1.0.0), libncurses5 (>= 5.
4-5), libreadline5 (>= 5.2), libsm6, libx11-6, libxaw7, libxext6, libxmu6, libxt
6, tcl8.4 (>= 8.4.5), tk8.4 (>= 8.4.5), debconf (>= 0.5) | debconf-2.0, gcc, deb
conf (>= 1.2.0)
Suggests: gcl-doc
Filename: pool/main/g/gcl/gcl_2.6.7-32_amd64.deb
Size: 33929666
MD5sum: 1846a63096382273dfd4cf7652d224c8

In particular there is no dependency on developement libraries, so
it is passible that current Debian have similar problem.

-- 
                              Waldek Hebisch
address@hidden 











reply via email to

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