From: Nikodemus S. <nik...@ra...> - 2008-10-09 17:27:51
|
On Thu, Oct 9, 2008 at 7:49 PM, Gabriel Dos Reis <gd...@in...> wrote: > The way I was seeing this was that I was under the impression > that I could define a foreign function -- without loading the foreign > library first -- and as long as I do not call that function, every > thing is OK. But, I would have to load the library before the > first use of the foreign function. Correct. > Is that impression just a side-effect of implementation details? Yes and no. It is an intentional side-effect, if you will -- but one that doesn't exist everywhere, only on platforms where linkage table is implemented. > By extension, I thought that it could be quite possible to unload the > libraries before save-and-die, and reload them on start up before > calling the foreign function. Yes. I've worked out a patch that adds a :DONT-SAVE keyword to LOAD-SHARED-OBJECT, requesting it to be dropped when SAVE-LISP-AND-DIE is called. (See sbcl-devel for details.) It needs (at least) one more testing round on Windows before going in, though. > Hmm, I was hoping I would not have resort to LD_LIBRARY_PATH especially > because I was want to run on Windows, where the search path rules > differ. Right. (Actually, Windows is in need of some love here: it seems that linkage table is not getting currently used on there -- which means that any references to foreign addresses from shared objects may go stale at SAVE-LISP-AND-DIE time. I suspect fixing it is just a matter of putting the linkage-table updating calls back in, but I'm not sure.) > Is there a hope for 'static linking' with SBCL? Not sure what this means, unless you mean the "manually relink the sbcl runtime to contain all your foreign code" trick Thomas mentioned. Cheers, -- Nikodemus |