Shared/static libraries in static-program-op context

[Florian Margaine]

Good morning cffi-devel,

I have been recently sending a bunch of pull requests:

- https://github.com/cffi/cffi/pull/162
- https://github.com/cffi/cffi/pull/157

Which are really the following issue:

- CFFI loads a static foreign library, either as :grovel-wrapper or :system
- The image is dumped with the loaded library
- When restored, the runtime will try to reload those "shared" libraries
and fails because the path doesn't exist on the target system

Specifically for the 2nd one, CFFI provides a :c-file ASDF integration,
which, when used with :static-program-op, will compile the C file into an
object file (among others), load it as a foreign library, and statically
link the object file with the program.

In order to make it possible to distribute this static-program-op output,
we essentially need to close the foreign library (IOW unload it), or not
load it to begin with, before dumping the image. That means tracking those.
The 2nd PR I made, as sionescu pointed out, doesn't work because C-FILE
code isn't aware of whether it's going to be used for static-program-op or
not.

So I can see 2 ways out of this:

- Either we make FOREIGN-LIBRARY-TYPE settable from the outside (remember
that CFFI-TOOLCHAIN is not in the CFFI package), which doesn't sound like
the correct way to go to me?
- Or we add a CLOSE-ON-DUMP option, which we can use when registering the
library. (Btw, that means exposing the REGISTER-FOREIGN-LIBRARY symbol, but
that sounds uncontroversial to me.)

Both of the PRs I mentioned earlier would benefit this CLOSE-ON-DUMP
option. Instead of having to manually go through the foreign libraries and
guess which ones need to be closed before dumping, this option would be
explicit.

What do you think?

Regards,

-- 
Florian Margaine
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/cffi-devel/attachments/20200524/e90f81b8/attachment.htm>