<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, May 25, 2020 at 1:19 AM Stelian Ionescu <<a href="mailto:sionescu@cddr.org">sionescu@cddr.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Sun, 2020-05-24 at 21:57 +0200, Florian Margaine wrote:<br>
> Good morning cffi-devel,<br>
> <br>
> I have been recently sending a bunch of pull requests:<br>
> <br>
> - <a href="https://github.com/cffi/cffi/pull/162" rel="noreferrer" target="_blank">https://github.com/cffi/cffi/pull/162</a><br>
> - <a href="https://github.com/cffi/cffi/pull/157" rel="noreferrer" target="_blank">https://github.com/cffi/cffi/pull/157</a><br>
> <br>
> Which are really the following issue:<br>
> <br>
> - CFFI loads a static foreign library, either as :grovel-wrapper or<br>
> :system<br>
> - The image is dumped with the loaded library<br>
> - When restored, the runtime will try to reload those "shared"<br>
> libraries<br>
> and fails because the path doesn't exist on the target system<br>
> <br>
> Specifically for the 2nd one, CFFI provides a :c-file ASDF<br>
> integration,<br>
> which, when used with :static-program-op, will compile the C file<br>
> into an<br>
> object file (among others), load it as a foreign library, and<br>
> statically<br>
> link the object file with the program.<br>
> <br>
> In order to make it possible to distribute this static-program-op<br>
> output,<br>
> we essentially need to close the foreign library (IOW unload it), or<br>
> not<br>
> load it to begin with, before dumping the image. That means tracking<br>
> those.<br>
> The 2nd PR I made, as sionescu pointed out, doesn't work because C-<br>
> FILE<br>
> code isn't aware of whether it's going to be used for static-program-<br>
> op or<br>
> not.So I can see 2 ways out of this:<br>
> <br>
> - Either we make FOREIGN-LIBRARY-TYPE settable from the outside<br>
> (remember<br>
> that CFFI-TOOLCHAIN is not in the CFFI package), which doesn't sound<br>
> like<br>
> the correct way to go to me?<br>
> - Or we add a CLOSE-ON-DUMP option, which we can use when registering<br>
> the<br>
> library. (Btw, that means exposing the REGISTER-FOREIGN-LIBRARY<br>
> symbol, but<br>
> that sounds uncontroversial to me.)<br>
<br>
I don't think either of those are a good idea because they're not<br>
solving the problem at its core: 1) the wrapper shared objects are<br>
loaded by absolute path and 2) the filesystem layout differs between<br>
host and target machine<br>
<br>
To fix that you need to either<br>
 * keep the .so as they are, and have static-program-op output a<br>
directory containing the output binary and all the wrappers, then fixup<br>
the wrapper paths so that the runtime finds the shared objects in their<br>
new location (might need to close them and have them re-opened on<br>
start). This is what most other dynamic language runtimes do (Perl,<br>
Python, etc...)<br>
 * statically link the wrapper: make the wrapper op also generate a<br>
static archive (.a), then link to that in static-program-op<br></blockquote><div><br></div><div>The static link is already what static-program-op is doing. The problem is that the foreign library is _also_ loaded as a shared library, and is restored when the image restores itself. Which fails with the wrong paths.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
--<br>
Stelian Ionescu a.k.a. fe[nl]ix<br>
Quidquid latine dictum sit, altum videtur.<br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><font color="#999999">Florian Margaine</font><br></div></div></div>