Re: validity of foreign functions across saved images

> For example, currently I'm thinking about ways to provide an API about how to revalidate foreign functions after being restarted from an ancient image.
> 
> The thing is,
> (DEF-ALIEN-ROUTINE #)
> (DEF-CALL-OUT #)
> etc. all presuppose that the (C) function is already known somehow (e.g. shared library is open at time these forms are evaluated).
> 
> What is when you once evaluated these forms, saved your image and restart from that saved image? Probably a crash. How to address this portably?
> 
> 
> CLISP's module concept solves this at the cost of not being able to dynamically call any function, which I find not acceptable. Only the functions in the binary are known(!).
> 
> Using CMUCL, we managed to build images which had an :INIT-FUNCTION so as to reload a foreign object file at the same address as previously, and perhaps load the actual definitions only then, with just a package stub in the image (I cannot exactly remember what I did >5 years ago). So it was a "mostly complete" image, and not really a restart, rather than a "prepare image with foreign functions".

I see the problem. For MaiSQL, Pierre worked hard to keep the crypt
foreign call to be evaluated at load time for the postgresql-native
interface. Insted, he wrote a wrapper to define the foreign call at run
time. That way, he could save an image with the code. His solution was a
bit cumbersome.  I do something similar in CLSQL with UFFI in the 
postgresql-socket interface.

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.

Kevin