On Sun, Jul 02, 2000 at 09:32:31PM +0100, Daniel Barlow wrote:
(..and I said that I'd try to put this stuff into the next version,
and I've been working on that today..)
> The commentary in src/code/foreign.lisp indicates that dynamic loading
> was disabled in SBCL. Cursory fiddling indicates that all that is
> required to get it working again is to
> 1) uncomment it, and
Good, I can handle that..
> 2) for a CMUCL-compatible interface, implement RUN-PROGRAM, which is
> used to run ld(1) (to agglomerate the user-supplied object file with
> the relevant libraries) then
I took a look at this, and decided that this is more fun than I really
want to have right now. It's obviously a very useful extension,
though, both for application progammers to use directly and for the
system to use for things like calling ld, finding uname information,
and so forth, so I left my slightly-ported version of RUN-PROGRAM in
src/code/run-program.lisp in anticipation of it getting done someday.
> 3) it would ne nice to fix the probable security hole caused by using
> an easily guessable filename in /tmp
I didn't try to fix this, but I did make a comment noting that it
would be a good thing for someone to do so.
> Note that even without RUN-PROGRAM, step (1) on its own is useful
> functionality as it means we can load shared libraries:
> $ cc -c -o get_h_errno.o get_h_errno.c
> $ ld -shared -o get_h_errno.so get_h_errno.o
> * (load-object-file "/home/dan/src/telent/sockets/get_h_errno.so")
> (#.(INT-SAP #X08264D28) #.(INT-SAP #X400130D0))
True enough, that looks useful. I have
* renamed LOAD-OBJECT-FILE to LOAD-1-FOREIGN and exported it from SB-EXT;
* changed its return value to T (on the theory that it's like CL:LOAD); and
* added some documentation based on your example above.
William Harold Newman <william.newman@...>
PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C