[cffi-devel] Unloading libraries for delivery

[John Fremlin]

John Fremlin <jf at msi.co.jp> writes:
> Luís Oliveira <luismbo at gmail.com> writes:
>> On Fri, Jan 30, 2009 at 6:05 AM, John Fremlin <jf at msi.co.jp> wrote:
>>> Luis, would you consider a patch to add a special variable
>>> *cffi-wrapper-delay-load* which would set a special mode for the
>>> generated wrapper.lisps?
>>
>> I'd rather solve the problem in a more general way. (And document it
>> in the manual.) Every library out there calls LOAD-FOREIGN-LIBRARY at
>> load-time. What can we do to make that work in delivery-friendly way?
>
> That's a really good point. Even if you give a quite extensive selection
> of places to search for a library in, when the image is dumped the one
> location where it was found on the dumping machine is stored in the
> image. Restarting the image will crash before reaching user code, if
> the library is not in the exact same place (as I understand it).
>
> The ability to unload all libraries before dumping makes a lot of
> sense.

Here is a preliminary patch that does exactly that.

I have tested it very briefly on Lispworks 5.1.2 and SBCL 1.0.29, both
AMD64 only.

Note that these features are not necessary for Allegro, which is our
primary platform, as it copies non-standard shared objects into the
delivery directory. This is to support testing our application on other
platforms.

The patch is a little complex and touches on many areas.






>
>> Not using absolute paths is one way, but is that not enough for the
>> wrapper libs?
>
> The C libraries for wrapper files are generated inside the source
> directory, or wherever asdf decides to put them. This generally means
> that delivery without source (or at least, without the structure of the
> source tree) is inconvenient.
>
> It would be great if the list of the generated libraries could be
> queried at delivery time, so they can all be copied into a destination
> directory. 
>
> Then something like the patch I sent to try to load them from a
> selection of locations (perhaps these should be more user-configurable?)
> would solve the problem.
>
> (Of course, it should also be possible to bundle them all up into a
> single library file and even store that in the Lisp image. But that
> sounds like more than a few lines of work...)
>
>> Perhaps CFFI can unload the foreign libraries before delivery and take
>> care of reloading them later, thereby providing
>> *FOREIGN-LIBRARY-DIRECTORIES* and, eventually, error-handling hooks?
>
> A function that unloaded all libraries and we could call before dumping
> the image would be great.
>
> _______________________________________________
> cffi-devel mailing list
> cffi-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/cffi-devel