Return to BSD News archive
Newsgroups: comp.os.386bsd.apps
Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!elroy.jpl.nasa.gov!usc!cs.utexas.edu!utah-morgan!hellgate.utah.edu!fcom.cc.utah.edu!cs.weber.edu!terry
From: terry@cs.weber.edu (A Wizard of Earth C)
Subject: Re: LISP on 386BSD?
Message-ID: <1993May21.223146.25224@fcom.cc.utah.edu>
Sender: news@fcom.cc.utah.edu
Organization: Weber State University (Ogden, UT)
References: <C7E5Jv.MAw@nmrdc1.nmrdc.nnmc.navy.mil>
Date: Fri, 21 May 93 22:31:46 GMT
Lines: 41
In article <C7E5Jv.MAw@nmrdc1.nmrdc.nnmc.navy.mil> dsc3pzp@nmrdc1.nmrdc.nnmc.navy.mil (Philip Perucci) writes:
>Anyone know if AKCL and/or CLISP compile *cleanly* with 386BSD, or
>if porting is required? Even general comments on the compatibilty
>of the 386BSD libraries with common packages (perl, emacs, XFree,
>xarchie, gopher) greatly appreciated. I really like to compile
>myself, but hate to port packages - don't have much time to play
>and like to USE the packages rather than de-bug them.
I believe these packages are available on agate.berkeley.edu under the
"0.1-ports" (or a name real close to that) under the 386BSD directory. I
believe there is also an SBProlog and a Scheme, but I'm not sure.
(A)KCL has a slight distribution problem if modified (at least the last
time I looked at it). There is also a potential conflict, in that there
was a hack reported to be required to the exec() code to be able to store
extension information beyond the expected end of the a.out (the expected
end of the a.out was seen as a hard limit, and if the a.out was longer
than expected, it wouldn't run). (A)KCL used this area for extension
to LISP.
The conflict is one with the shared libraries. I have modified the exec
so it looks past the end of the a.out if the file is larger than expected
by the header information and segment sizes, and if so, decodes another
"header" there that allows the division of subsequent data into named
sections (I did this to avoid the .so and crt.0 mods that would otherwise
be required for shared libs, and to allow backward compatability at the
loader with all existing code). The result is, (A)KCL will probably have
to use this header to extend in the future by way of providing a named
attribute for its own use. This isn't a heavy penalty, in my opinion,
and leaves us with atomic shared libs instead of a .so/.sa file division
and wierd changes to a.out and crt0.o.
Terry Lambert
terry@icarus.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.
--
-------------------------------------------------------------------------------
"I have an 8 user poetic license" - me