Re: Re: validity of foreign functions across saved images

Hoehle, Joerg-Cyril wrote:
> >image and restart from that saved image? Probably a crash. How 
> >to address this portably?

I don't know how to do this portably.

> >For ACL and LW, which don't evaluate the function address 
> >during compile
> >and load times, there is not the same problem with saving an image that
> >has the foreign call definitions at the top level.
> When do they do it?

I think we are talking about two different thing.
- When are foreign func address resolved?
- How to reload an image that refers to a foreign-function address?

I think some of the difference that I've seen with ACL/LW vs. CMUCL is
that ACL/LW will merely warn when they can't resolve a foreign
function address during a compile where as CMUCL will signal an error.
I believe that ACL/LW likely resolve a function address at load time
where is CMUCL does this at compile time. Thus, Pierre Mai had so do
some gryations to get his FFI to the crypt function in his socket
interface to be evaluated at runtime. His goal was to deliver a dumped
image as an application without any .so files other than standard
system library which had the crypt function.

As for the second question, the following is from the AllegroCL dumplisp.htm
documentation file:

17.0 How the dumped image finds loaded library files

Foreign loading is done on Unix by `loading' .so or .sl files with
dlopen() or an equivalent and on Windows by loading .dll files. Dumped
images must find these files when it starts up. 

The pathnames of loaded .so files are stored. So long as those
pathnames are valid when the image is restarted, things should work
correctly. However, to guarantee that the dumped image finds the .so
files when it restarts, even if run on a different machine or network,
you can use one of the following methods. 

1.  Use pathnames that will be valid when the dumped image restarts
(and, as we describe, logical pathnames can be made valid in the
dumped image); or 
2.     Unload the .so files prior to dumplisp and reload them as part
of the startup procedure (perhaps as an action taken by
*restart-init-function*). We describe both methods in some detail.

> I'm still seeking a concept for doing this for CLISP (or whatever)
> across saved images.

Sure. I know that you were working on dynamic loading of shared
libraries during a single session. Have you finished tha, and now you
are working on doing this across saved images?

The Allegro docs don't mention this. But, what if the .so file was
recompiled between executions with the saved image? I assume this is
invalid and will fail, but the docs don't specifically state this.

The docs do discuss point #2 above, which is likely the safest way to
go:

"Unloading all .so files and reloading them upon startup. In this
example, we unload the (in our case single) .so file with
ff:unload-foreign-library and show how to modify
*restart-init-function* so the .so file is reloaded."

Best,

Kevin