Subject: mailing-list for TeXmacs Users
List archive
From : Enrique Perez-Terron <address@hidden>- To: address@hidden, address@hidden
- Cc: texmacs-users <address@hidden>
- Subject: Re: [TeXmacs] A rewrite of tm_axiom.c (attached)
- Date: Tue, 13 Oct 2009 01:57:32 +0200
I have just downloaded open-axiom-1.3.0.tar.bz2, and attempted to build
it using the standard installed gcl from Fedora 11.
I think the builders of Fedora-11 downloaded a CVS snapshot of gcl on
some date... Yes, here it is, in their gcl.spec:
# The source for this package was pulled from upstream's CVS repository. Use
# the following commands to generate the tarball:
# cvs -d:pserver:address@hidden:/sources/gcl export \
# -r Version_2_6_8pre -D 2009-03-04 -d gcl-2.6.8 gcl
# tar -cjvf gcl-2.6.8.tar.bz2 gcl-2.6.8
But the code quoted below is not different in the cvs snapshot I myself
downloaded (without version and date restricting options) on 2009-10-07.
(There are differences in other parts of plt.c and fasdump.c.)
I am building on Fedora 11, with SELinux disabled:
$ sudo getenforce
Disabled
Also relevant:
$ ld --version
GNU ld version 2.19.51.0.14-1.fc11 20090722
...
$ gcc --version
gcc (GCC) 4.4.1 20090725 (Red Hat 4.4.1-2)
$ gcl --version
GCL (GNU Common Lisp) 2.6.8 ANSI Apr 27 2009 12:50:17
...
Just in case: (compare the build date)
$ rpm -qi gcl
Name : gcl Relocations: (not relocatable)
Version : 2.6.8 Vendor: Fedora Project
Release : 0.3.20090303cvs.fc11 Build Date: Mon 27 Apr 2009
06:54:29 PM CEST
...
(The text below was written for a different mailing list, but I decided
to send to more appropriate lists when I saw what I have written. Bear
with the excessive details.)
During the build of open-axiom, the following command:
> echo '(let* ((sys-cc compiler::*cc*) ' \
> ' (sys-ld compiler::*ld*) ' \
> ' (compiler::*cc* (concatenate (quote string) ' \
> ' "../../libtool
> --mode=compile " ' \
> ' sys-cc)) ' \
> ' (compiler::*ld* (concatenate (quote string) ' \
> ' "../../libtool --mode=link
> " ' \
> ' sys-ld))) ' \
> '(compiler::link (quote ("core.o")) "lisp" ' \
> ' (format nil "(progn (let ((*load-path* (cons ~S
> *load-path*))'\
> ' (si::*load-types* ~S)))' \
> ' (when (fboundp (quote si::sgc-on))' \
> ' (si::sgc-on nil))' \
> ' (setq si::*top-level-hook*
> (read-from-string \"|AxiomCore|::|topLevel|\")))"' \
> ' si::*system-directory* (quote (list ".lsp")))' \
> ' "./../../src/lib/bsdsignal.o ./../../src/lib/cfuns-c.o
> ./../../src/lib/sockio-c.o -lutil -lm"))' \
> | ./base-lisp
fails with the following output:
> GCL (GNU Common Lisp) 2.6.8 ANSI Apr 27 2009 12:50:17
> 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/
>
> AxiomCore>libtool: compile: gcc -c -O2 -g -pipe -Wall
> -Wp,-D_FORTIFY_SOURCE=2 -m32 -march=i586 -mtune=generic
> -fasynchronous-unwind-tables -Wall -DVOL=volatile -fsigned-char -pipe
> -I/usr/lib/gcl-2.6.8/unixport/../h -O2 -fno-strict-aliasing -c
> ./user-init.c -w -fPIC -DPIC -o ./.libs/user-init.o
> libtool: compile: gcc -c -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -m32
> -march=i586 -mtune=generic -fasynchronous-unwind-tables -Wall
> -DVOL=volatile -fsigned-char -pipe -I/usr/lib/gcl-2.6.8/unixport/../h -O2
> -fno-strict-aliasing -c ./user-init.c -w -o ./user-init.o >/dev/null 2>&1
> libtool: link: gcc -o ./raw_lisp ./user-init.o core.o -Wl,-Map
> ./raw_lisp_map ./../../src/lib/bsdsignal.o ./../../src/lib/cfuns-c.o
> ./../../src/lib/sockio-c.o -L/usr/lib/gcl-2.6.8/unixport/ -lansi_gcl -lSM
> -lICE -lXmu -lXt -lXext -lXaw -lX11 -lgmp -lbfd -liberty -lreadline
> -lncurses -lc -lgclp -lutil -lm
> GCL (GNU Common Lisp) April 1994 131072 pages
> Cannot read address
> Lisp initialization failed.
>
> "lisp"
>
> AxiomCore>
I am building using the Fedora-11 native gcl. The command "./base-lisp"
appears to be a version of gcl that has been dumped with some extra
functions and a modified prompt "AxiomCore", a few lines earlier in the
build.
I had the same error a few days ago, and I looked at the gcl source to
find the error message "Cannot read address". I found it in
gcl-2.6.8/o/plt.c, and it appears that the function parse_plt() *must*
fail with exactly this message given the input file
src/lisp/raw_lisp_map (from the open-axiom build tree).
The input file contains:
> Archive member included because of file (symbol)
>
> /usr/lib/gcl-2.6.8/unixport//libansi_gcl.a(alloc.o)
> ./../../src/lib/cfuns-c.o (free)
> /usr/lib/gcl-2.6.8/unixport//libansi_gcl.a(cmpaux.o)
> ./user-init.o (gcl_init_or_load1)
( ... lots of stuff, then )
> .plt 0x000000000804ebd4 0x27b0
> *(.plt)
> .plt 0x000000000804ebd4 0x27b0
> /usr/lib/gcc/i586-redhat-linux/4.4.1/../../../crt1.o
> 0x000000000804ebe4 fileno@@GLIBC_2.0
> 0x000000000804ebf4 getpagesize@@GLIBC_2.0
> 0x000000000804ec04 XWidthOfScreen
> 0x000000000804ec14 fputs@@GLIBC_2.0
> 0x000000000804ec24 abort@@GLIBC_2.0
> 0x000000000804ec34
> __errno_location@@GLIBC_2.0
> 0x000000000804ec44 XXorRegion
( ... many similar lines ... )
> 0x0000000008051314 getgid@@GLIBC_2.0
> 0x0000000008051324 XSetScreenSaver
> 0x0000000008051334 XChangeWindowAttributes
> 0x0000000008051344 __gmpz_add_ui
> 0x0000000008051354 XSetArcMode
> 0x0000000008051364 XParseGeometry
> 0x0000000008051374 geteuid@@GLIBC_2.0
> *(.iplt)
> .iplt 0x0000000000000000 0x0
> /usr/lib/gcc/i586-redhat-linux/4.4.1/../../../crt1.o
>
> .text 0x0000000008051390 0x33d9dc
> *(.text .stub .text.* .gnu.linkonce.t.*)
> .text 0x0000000008051390 0x24
> /usr/lib/gcc/i586-redhat-linux/4.4.1/../../../crt1.o
> 0x0000000008051390 _start
> .text 0x00000000080513b4 0x0
> /usr/lib/gcc/i586-redhat-linux/4.4.1/../../../crti.o
> *fill* 0x00000000080513b4 0xc 90909090
( ... etc.)
The code:
> for (i=j=0,li=Cnil;fgets(b,sizeof(b),f);) {
(initialize variable "i" to zero; then repeat reading lines from file
"f" into buffer "b", and for each line ...)
> if (!memchr(b,10,sizeof(b)-1))
> FEerror("plt buffer too small", 0);
(fail with an error message if no newline character (code 10) is found
in the buffer (i.e. the input line was too long to fit), ...)
> if (memcmp(b," .plt",4) && !i)
> continue;
("continue" - ie. read the next input line - unless a) "b" begins with
" .pl", or b) "i" is non-zero. "i" works like a switch, set it to 1 to
activate the code below for input lines not having " .pl"...)
(--notice the strange digit 4 when the string literal has 5 characters
including the leading space. A minor bug? --)
> if (*b=='\r' || *b=='\n') {
> i=0;
> continue;
> }
(turn the switch off again when processing an empty line ... )
> else
> if (!i) {
> i=1;
> continue;
> }
( If the switch is off, turn it on, but go back up and get the next
input line before doing anything more. This prevents the code below
from acting on the line that begins with " .pl".)
We can only get past this point when the switch is on. The extraction
happens with
> if (sscanf(b,"%lx%n",&u,&n)!=1)
> FEerror("Cannot read address", 0);
which must fail when we reach the line that has "*(.iplt)" at the
start.
I tell all this because the web is full of messages about the problems
with Fedora and SELinux, but I have SELinux disabled, and this does not
look like a compiler bug or a compiler over-optimization.
Obviously the program expects the input to have an empty line separating
distinct parts. Maybe some tool has been changed. Maybe there used to be
an empty line just before the "*(.iplt)" line, or may be two lines
containing .iplt have been added in a recent version of the tools that
generate the map file. I have
OK, I "fixed" it, by placing a shell script "ld" in /usr/local/bin,
which is ahead of /usr/bin in my path:
> #!/bin/sh
>
> set -x
>
> case "$*" in
> (*"-Map ./raw_lisp_map"*)
> /usr/bin/ld "$@"
> mv ./raw_lisp_map ./raw_lisp_map.old
> grep -v '\.iplt' ./raw_lisp_map.old > ./raw_lisp_map
> ;;
> (*)
> exec /usr/bin/ld "$@"
> ;;
> esac
but I immediately ran into the next problem:
> GCL (GNU Common Lisp) April 1994 131072 pages
> Building symbol table for /home/enrique/src/build-oa/src/lisp/raw_lisp ..
> loading /usr/lib/gcl-2.6.8/unixport/../lsp/gcl_export.lsp
> Initializing gcl_defmacro.o
> Can't open file ~s
> Lisp initialization failed.
>
> "lisp"
>
> AxiomCore>
I found the following line in the source of gcl, in file o/fasdump.c:
> if (in == Cnil)
> FEerror("Can't open file ~s",1,d);
I wonder if the string "~s" should have been "%s" ...
By the way, some days ago I build my CVS snapshot of gcl; this was only
possible after adding -fno-strict-aliases to TCFLAGS in ./configure
Enrique
- [TeXmacs] A rewrite of tm_axiom.c (attached), Enrique Perez-Terron, 10/10/2009
- Re: [TeXmacs] A rewrite of tm_axiom.c (attached), Kostas Oikonomou, 10/12/2009
- Re: [TeXmacs] A rewrite of tm_axiom.c (attached), Bill Page, 10/12/2009
- Re: [TeXmacs] A rewrite of tm_axiom.c (attached), Kostas Oikonomou, 10/12/2009
- Re: [TeXmacs] A rewrite of tm_axiom.c (attached), Enrique Perez-Terron, 10/12/2009
- Re: [TeXmacs] A rewrite of tm_axiom.c (attached), Bill Page, 10/12/2009
- Message not available
- Re: [TeXmacs] A rewrite of tm_axiom.c (attached), Enrique Perez-Terron, 10/13/2009
- Re: [TeXmacs] A rewrite of tm_axiom.c (attached), Enrique Perez-Terron, 10/13/2009
- Re: [TeXmacs] A rewrite of tm_axiom.c (attached), Joris van der Hoeven, 10/12/2009
Archive powered by MHonArc 2.6.19.