On Thu, Oct 9, 2008 at 12:00 PM, Nikodemus Siivola
> On Thu, Oct 9, 2008 at 7:49 PM, Gabriel Dos Reis
> <gdr@...> 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.
>> 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.)
This is great! Many thanks.
> 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
> (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.
What I meant was something like that, yes: Basically, an officially
documented way to rebuild the SBCL runtime by including my own .o files
(that contain my foreign functions). That would side step the
library path issues at the expense of including more codes than