#542 Solaris 10/Sparc: control characters in FAS files
Building clisp from cvs (including a checkout from 17. Feb. 2010) fails to build on my solaris boxes with the following message:
mv lispimag.mem interpreted.mem
./lisp.run -B . -N locale -E UTF-8 -Epathname 1:1 -Emisc 1:1 -norc -m
2MW -M interpreted.mem -q -c compiler.lisp -o ./
;; Compiling file /opt/src/clisp/src/compiler.lisp ...
;; Wrote file /opt/src/clisp/src/compiler.fas
0 errors, 0 warnings
./lisp.run -B . -N locale -E UTF-8 -Epathname 1:1 -Emisc 1:1 -norc -m
2MW -lp -x '(and (load "init.lisp") (sys::%saveinitmem) (ext::exit))
(ext::exit t)'
[...]
;; Loaded file /opt/src/clisp/src/trace.lisp
;; Loading file /opt/src/clisp/src/cmacros.lisp ...
;; Loaded file /opt/src/clisp/src/cmacros.lisp
*** - READ from #<INPUT BUFFERED FILE-STREAM CHARACTER
#P"/opt/src/clisp/src/compiler.fas" @>: illegal character #\Etb
Bye.
gmake: *** [halfcompiled.mem] Error 1
My build environment:
- gcc and dependencies are installed in /opt/csw (the OpenCSW package repository)
% uname -a
SunOS host 5.10 Generic_141414-07 sun4v sparc SUNW,T5240
% gcc -v
Using built-in specs.
Target: sparc-sun-solaris2.8
Configured with: ../gcc-4.3.3/configure --prefix=/opt/csw/gcc4
--exec-prefix=/opt/csw/gcc4 --with-gnu-as --with-as=/opt/csw/bin/gas
--without-gnu-ld --with-ld=/usr/ccs/bin/ld --enable-nls
--with-included-gettext --with-libiconv-prefix=/opt/csw --with-x
--with-mpfr=/opt/csw --with-gmp=/opt/csw --enable-java-awt=xlib
--enable-libada --enable-libssp --enable-objc-gc
--enable-threads=posix --enable-stage1-languages=c
--enable-languages=ada,c,c++,fortran,java,objc
Thread model: posix
gcc version 4.3.3 (GCC)
% ./configure --prefix=/opt/software/clisp-devel-20100128
The file in question (compiler.fas), which, according to the error, contains invalid characters.
the first 4 lines of compiler.fas show the problem:
(|SYSTEM|::|VERSION| '(.))
#0Y_ #0Y |CHARSET|::|UTF-8|
#Y(#:| (IN-PACKAGE "COMMON-LISP")-|
#ººY(00 00 00 00 00 00 00 00 20 01 DA 31 F6 0F 01 19 01)
instead of decimal digits we see either ^W (#\Etb, #\Code23) - inside || and ()
or #\MASCULINE_ORDINAL_INDICATOR (#\Code186) - between # and Y.
now, the question is - why.
1. please try to reproduce this interactively:
$ ./lisp.run -M interpreted.mem -norc
do you see a "[1]>" prompt or do you see something weird between []?
what do you see when you type "42" and hit return?
how about |42|? (42)?
2. please try to rebuild clisp with debugging symbols (either configure with "./configure --with-debug --cbc build-g" or
edit Makefile to replace "-O" with "-g" in CFLAGS and then do "make clean; make").
1. In short, there seems to be an error related to numbers: this is the output:
[,,]> (1)
*** - EVAL: is not a function name; try using a symbol instead
The following restarts are available:
USE-VALUE :R Input a value to be used instead.
ABORT :R Abort main loop
Break [,,]> abort
[,,]> |42|
*** - SYSTEM::READ-EVAL-PRINT: variable |42| has no value
The following restarts are available:
USE-VALUE :R Input a value to be used instead of |42|.
STORE-VALUE :R Input a new value for |42|.
ABORT :R Abort main loop
Break [,,]> abort
[,,]> (+ 1 1)
[,,]> 42
So both giving numbers on the command line and doing calculations don't return anything.
2. I'm currently having other difficulties compiling clisp. I'll post them to the list because they are related to gllib, which probably means that they aren't related to this problem.
the problem seems to be only with _printing_ of _numbers_
e.g., please try (zerop (- 1 1)) - you will probably see T.
what happens with floats? what do you see when you type 1s0, 1f0, 1d0, 1l0?
the function to debug is lisparit.d:print_integer
note: unix/PLATFORMS say:
* On Sparc running Solaris 8, 9, 10:
Use gcc 3.3.* because gcc 4.* miscompiles at least io.d.
see also
<http://article.gmane.org/gmane.lisp.clisp.general/12587>
<http://article.gmane.org/gmane.lisp.clisp.general/12593>
This is a gcc bug, not a clisp bug.
This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).
This appears to not be due to a GCC 3.x bug, because I still observe similar broken .fas files on Linux/sparc with safety 0, with gcc-4.6.3.
See also https://sourceforge.net/p/clisp/bugs/564/