axiom-developer
[Top][All Lists]
Advanced

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

Re: [Axiom-developer] Building Axiom 11/15/2004 on Solaris 9 Sparc


From: Camm Maguire
Subject: Re: [Axiom-developer] Building Axiom 11/15/2004 on Solaris 9 Sparc
Date: 29 Nov 2004 19:20:24 -0500
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

Greetings, and please excuse the delay in my reply (holiday weekend
here).

I am reasonably confident you have one of two possible problems on
solaris:

1) Recent Solaris ld can place the .text section at other locations
   than at the beginning of the file.  The first patch at

        http://www.gnu.org/software/gcl/ERRATA-2.6.5.html

   fixes this.  This was needed for an ACL2 build on more recent
   solaris, for example.  We didn't catch it before 2.6.5 was released
   as the solaris machine to which I had access was not updated as of
   that time.

2) If gmp is not found externally, GCL will build its own copy.  I
   occasionally have seen gmp's configure mis-guess the solaris
   version, and compile in v9 extensions on a machine which could not
   handle them.  If this is the case, you should be able to see the
   effect on multiplying two bignums in the first lisp image,
   mnt/???/bin/lisp.  This can be fixed by explicitly providing the
   host type to the gmp subconfigure -- please let me know if you feel
   this is applicable and I will supply details.

In addition, as you may know, binutils upstream has made some binary
incompatible changes since 2.6.5 was released.  I think the last patch
at the aforementioned page should work with all extant versions, but
this still has to be tested.  In the meantime, I highly recommend
using the binutils in the GCL source directory.  This can be achieved
by using --disable-statsysbfd --enable-locbfd at the GCL configure
command line.  Tim can show you which pamphlet stanza you need I
think.

As an aside, I originally wrote an interface for bfd relocations as
both an aid to portability for this great GCL feature, and as a means
to offload this tedious highly platform specific component.  The goal
was to use an external bfd library and keep the build modular.  We
have since learned from binutils upstream that they have no intention
of any outside code using libbfd, will break the api at any time, and
indeed recommend distros removing the .so link needed to compile
against the library dynamically.  In principle, the soname of the
library could track api changes, but in practice this happens so often
as to force a rebuild of all GCL software every few months or so.  We
therefore link in statically, but the danger here is that someone
moves the binary between compilation machine to runtime machine where
the two have incompatible bfd libs present -- in such a case, GCL's
compiler::link function will break.  So in sum, as much as I dislike
such forking of other people's code, (sheepish smile in Tim's
direction), the best option we have now is to use the local bfd copy
-- resulting images should be then completely portable.  Furthermore,
Aurelien has written excellent MacOSX support which to my
understanding has not yet been accepted in the official binutils
upstream.  If we come to the conclusion that there is no modular
external portable relocation engine we can use, and rather must
supply our own, then we will either be developing the local binutils
tree on a regular basis, or moving gradually over time to the older
relocation option native to GCL (--enable-custreloc at the configure
command line, only on sparc and i386 at present).

One last note no bfd -- not sure if your situation is the same, but
on the solaris machine to which I have access, there is a longstanding
mismatch between the bfd headers and the binary libraries available on
the system.  I *had* to use the local bfd for this reason, at least on
this machine.  (If you want to test bfd, fire up the lisp, (defun foo
(x) x), then (compile 'foo)).

Finally, you are welcome to use CVS head, but I ask that you try to
stay away until it is released if possible.  We need to be able to
work n this version without the fear of breaking existing apps to
achieve our intended goal for the next release -- full ANSI
compliance.  2.6.5 has gone through an enormous amount of testing, and
should be a solid platform for axiom and other apps for the time
being.  This said, if the items on the ERRATA page above are too
annoying, we can push out a 2.6.6.

Take care,


"Kostas Oikonomou" <address@hidden> writes:

> Hello,
> 
> I am trying to compile the Axiom sources dated 11/15/2004 on a Sun Solaris 9 
> system.
> The build ends with lisp dumping core:
> 
> --------------------------------------------------------------------------------------------------
> Loading /home/build/axiom/int/boot/npextras.lisp
> Finished loading /home/build/axiom/int/boot/npextras.lisp
> Compiling tytree1.lisp.
> ; (DEFUN |bfMDef| ...) is being compiled.
> ;; Warning: The variable |defOp| is not used.
> End of Pass 1.
> End of Pass 2.
> OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=3
> Finished compiling /home/build/axiom/obj/solaris/boot/tytree1.o.
> 618a making /home/build/axiom/mnt/solaris/doc/src/boot/axiom.sty from 
> /home/build/axiom/src/doc/axiom.sty.pamphlet
> 3 making /home/build/axiom/mnt/solaris/doc/src/boot/boothdr.lisp.dvi from 
> /home/build/axiom/src/boot/boothdr.lisp.pamphlet
> 6 making /home/build/axiom/mnt/solaris/doc/src/boot/btincl2.lisp.dvi from 
> /home/build/axiom/src/boot/btincl2.boot.pamphlet
> 10 making /home/build/axiom/mnt/solaris/doc/src/boot/btpile2.boot.dvi from 
> /home/build/axiom/src/boot/btpile2.boot.pamphlet
> 14 making /home/build/axiom/mnt/solaris/doc/src/boot/btscan2.boot.dvi from 
> /home/build/axiom/src/boot/btscan2.boot.pamphlet
> 18 making /home/build/axiom/mnt/solaris/doc/src/boot/exports.lisp.dvi from 
> /home/build/axiom/src/boot/exports.lisp.pamphlet
> 21 making /home/build/axiom/mnt/solaris/doc/src/boot/npextras.lisp.dvi from 
> /home/build/axiom/src/boot/npextras.lisp.pamphlet
> 24 making /home/build/axiom/mnt/solaris/doc/src/boot/ptyout.boot.dvi from 
> /home/build/axiom/src/boot/ptyout.boot.pamphlet
> 28 making /home/build/axiom/mnt/solaris/doc/src/boot/tyextra.boot.dvi from 
> /home/build/axiom/src/boot/tyextra.boot.pamphlet
> 32 making /home/build/axiom/mnt/solaris/doc/src/boot/typars.boot.dvi from 
> /home/build/axiom/src/boot/typars.boot.pamphlet
> 36 making /home/build/axiom/mnt/solaris/doc/src/boot/typrops.boot.dvi from 
> /home/build/axiom/src/boot/typrops.boot.pamphlet
> 40 making /home/build/axiom/mnt/solaris/doc/src/boot/tytree1.boot.dvi from 
> /home/build/axiom/src/boot/tytree1.boot.pamphlet
> 44 invoking make in /home/build/axiom/src/boot with parms:
> SYS= solaris
> LSP= /home/build/axiom/lsp
> PART= cprogs
> SPAD= /home/build/axiom/mnt/solaris
> SRC= /home/build/axiom/src
> INT= /home/build/axiom/int
> OBJ= /home/build/axiom/obj
> MNT= /home/build/axiom/mnt
> Illegal Instruction - core dumped
> make[3]: *** [/home/build/axiom/obj/solaris/bin/bootsys] Error 132
> make[3]: Leaving directory `/home/build/axiom/src/boot'
> make[2]: *** [bootdir] Error 2
> make[2]: Leaving directory `/home/build/axiom/src'
> make[1]: *** [srcdir] Error 2
> make[1]: Leaving directory `/home/build/axiom'
> make: *** [
> bash-2.05$
> bash-2.05$ cd ../../obj/solaris/bin
> bash-2.05$ gdb -c core
> GNU gdb 6.1
> Copyright 2004 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for details.
> This GDB was configured as "sparc-sun-solaris2.8".
> Core was generated by `/home/build/axiom/obj/solaris/bin/lisp'.
> Program terminated with signal 4, Illegal instruction.
> #0  0x007affd0 in ?? ()
> (gdb) q
> bash-2.05$
> 
> --------------------------------------------------------------------------------------------------
> 
> I would appreciate any advice on how to deal with the problem.
> 
> Here is a detailed file showing what I had to do to build Axiom.  Note that I 
> had to
> tweak GCL a bit, as mentioned at the end of the file.
> 
> Thanks very much for your help.
> 
>                                       Kostas
> 
> 
> 
> 
> 
> Sources of November 15, 2004
> ============================
> 
> Preliminaries:
> 
> export AXIOM=/home/build/axiom/mnt/solaris
> export PATH=$AXIOM/bin:$PATH
> 
> Edit Makefile:
>       tar -> gtar
> 
> make noweb
> 
> Edit the shell script "mnt/solaris/bin/document" to set
> 
> weave="$AXIOM/bin/lib/noweave -delay -x"
> 
> 
> -------------------------------------------------------------------
> 
> 1. Edit Makefile.pamphlet to add [11pt] and
> 
> \usepackage[hypertex,colorlinks=true,linkcolor=blue,filecolor=webgreen,extension=dvi]{hyperref}
> 
> to get hyperlinks.
> 
> 2. Study Makefile.dvi, edit Makefile.pamphlet:
> 
> (a) Check the GCL version of GCL:
> 
> GCLVERSION=gcl-2.6.5
> 
> Then rm lsp/Makefile
> 
> NOTE: Axiom contains its own distribution of GCL!
> 
> (b)
> <<environment>>=
> SPD=$(shell pwd)
> SYS=$(notdir $(AXIOM))
> SPAD=${SPD}/mnt/${SYS}
> LSP=${SPD}/lsp
> <<GCLVERSION>>
> AWK=gawk
> GCLDIR=${LSP}/${GCLVERSION}
> SRC=${SPD}/src
> INT=${SPD}/int
> OBJ=${SPD}/obj
> MNT=${SPD}/mnt
> ZIPS=${SPD}/zips
> TMP=${OBJ}/tmp
> SPADBIN=${MNT}/${SYS}/bin
> INC=${SPD}/src/include
> CCLBASE=${OBJ}/${SYS}/ccl/ccllisp
> INSTALL=/opt/axiom
> COMMAND=/opt/axiom/bin/axiom
> TANGLE=${SPADBIN}/lib/notangle
> 
> (c) Add a <<Makefile.solaris>> chunk in section 2.  Should have really been
>      "solaris9g".
> 
> (d) Edit lsp/Makefile.pamphlet and globaly change @tar to @$(TAR).
> 
> 
> 2. Building the GCL within Axiom (or outside of it, for that matter) is a 
> mess!
> 
>   - I had to edit the patch
>       zips/gcl-2.6.5.cmpnew.gcl_cmpflet.lsp.patch
>     supplied by Axiom so that it would match, and to put "patch -l" in the
>     Makefile, so that this patch would ignore blanks.
>   - Do alias awk=gawk in the shell.
>   - Do export CFLAGS=-I/opt/csw/include in the shell, otherwise BFD won't
>     compile.  Why doesn't GCL use its own binutils subdirectory?
> 
> 
> _______________________________________________
> Axiom-developer mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/axiom-developer
> 
> 
> 

-- 
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah




reply via email to

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