William Harold Newman writes:
> On Thu, Sep 07, 2000 at 06:13:02PM +0200, Raymond Wiker wrote:
> > Here's my port of run-program & friends to SBCL. As you
> > can see below, it works for at least _one_ trivial example :-)
> I've now mostly integrated it into my sources, what's I'd like to
> check in as sbcl-0.6.7.4.
> Could you (Raymond, or for that matter anyone else who might know:-)
> clarify some things for me?
> * Why did you change DEFPARAMETER *TARGET-STATIC-SPACE-START*?
> I've been leaving the old values untouched because they work,
> and uncommented because the Old CMU CL Gods didn't comment
> things like that and I haven't reverse engineered this enough
> to comment them myself. I'd rather have explanatory comments
> there, and I suspect that whatever motivated your change would
> be a useful start.
I changed it when I changed src/runtime/sbcl to be a dynamic
executable (necessary for dlopen() and friends to work - under
FreeBSD, at least). Without this change, I was unable to mmap() the
static space segment, as the dynamic library (libc.so) ended up
overlapping this area. OpenBSD may have a different set of memory
It may be possible to rearrange the code in runtime.c so that
validate() is called before anything that makes use of libc.so. If so,
this would (hopefully) force the dynamic loader to place libc.so at a
Note: *TARGET-STATIC-SPACE-START* must match
STATIC_SPACE_START (in src/runtime/x86-validate.h) - kind of obvious,
but easy to forget (to me, at least!)
> * You included some patches to Gray streams stuff. Do these make
> Gray streams work?
No, I haven't got Gray streams working. IIRC, the changes in
the gray-streams files are mostly adding empty class member lists; I
think SBCL is more strict than CMUCL in this area.
> * Why did you do the ldso_stub functions differently than PVE's
> code in linux-stubs.S? Do you think it would be possible to do
> the stubification the same way in both OSes (either PVE's
> way, or your way)?
PVE's code looks _much_ better. The reason I overlooked this
file was because I was looking for the ldso_stub stuff in *.c files.
I'll see if I can get the same thing working for FreeBSD.
> Besides those questions, the only remaining issues I noticed were
> that SB-UNIX:UNIX-DUP, SB-UNIX:UNIX-IOCTL, and SB-UNIX:UNIX-PIPE
> are currently undefined. I figured that even without them, it's
> worth making a development snapshot, but I'll also probably try
> resurrecting the CMU CL sources for these functions some time in
> the next few days.
Hum. As long as you're resurrecting code, maybe you could look
for the code getenv (or possibly sb-sys:*environment*) as well? This
would be handy for CLX, for finding a default value for DISPLAY. It
would also be good to have (eventually) for setting up certain logical
pathnames (e.g, HOME and LIB) at startup time...
> > Note: There are some gratuitous differences between the
> > version of run-program.lisp in the 0.6.7 distribution and the one
> > I've been working with. This is partly because I started with a
> > copy from a CMUCL distribution, while the one in the 0.6.7
> > distribution already had a different set of changes. I'll take a
> > closer look at combining the two sometime later.
> I more or less combined them myself when I merged your patches.
> > I also include internet.lisp, which compiles and loads fine with
> > the patched 0.6.7. Further changes to internet.lisp and
> > package-data-list.lisp-expr are required to fully integrate it with
> > SBCL. My main interest in internet.lisp is that it provides
> > functionality required for CLX (actually, it's possible to use Daniel
> > Barlow's socket library instead). Should internet.lisp be added back
> > to SBCL?
> As I think I wrote in an earlier reply, I'd prefer this to be a
> library, perhaps in contrib/.
Sounds good. In that case, maybe there should be a support
file somewhere for compiling and loading in (parts of) the contrib/
> > # * (sb-ext:run-program "/bin/uname" '("-a") :output t)
> > # Linux hovik.gren.fast.no 2.2.14-5.0smp #1 SMP Tue Mar 7 21:01:40 EST 2000 i686 unknown
> Now I can do this too! Pretty cool..
> (And once I successfully check it into SourceForge CVS, y'all
> reading this can do it too.:-)
So now all SBCL'ers can find out what machine they're working
on without suspending SBCL :-)