>actually, I don't see why clisp should exit if dynload-modules fails.
>could you please debug this?
There's nothing to debug. SYS::dynload-modules invokes functionality normally only used when clisp starts up. In the startup code, all clisp does upon encountering an error is to call exit().
>> module regexp requires packages REGEXP
>> -- and CLISP exits :-(
Maybe SF still holds the patch I once submitted, where packages needed by modules were created on the fly?
However, perhaps more is needed than just this patch to make the scenario work. It needs a bit more thought.
>> It's not so nice that using dynload precludes creating images :-(
>I think this can be fixed in a fairly straightforward way.
This use-case also needs more thought.
Sam Steingold wrote:
>> gcc -shared -oregshared.o regex.o regexi.o
>> ../lisp.run -M ../lispinit.mem
>> (load"preload.lisp") ; preload
>> (sys::dynload-modules "regshared.so" '("regexp"))
>> (load"regexp.fas") ; post-load
>try the same with the i18n module (see src/TODO for expected errors).
I tried it on the Linux box. It worked. The tiny i18n testsuite passed.
I didn't even use -fPIC (IIRC, somebody explained whether -fPIC is needed long time ago in this list).
src/TODO mentions i18n.dll. So obviously, failure to load the code has to do with cygwin or some such on MS-Windows.
My wild guess is that dlopen() emulation is lacking there. It looks like it fails to resolve symbols present and exported in the current binary.
This would not surprise me that much since I believe a .dll is like an executable on its own, i.e. fully linked, with a set of entry points, whereas a .so is just an object file, waiting to be linked against a binary.
E.g. I'd even expect dlsym("_main",NULL-handle-means-local-code) to fail, however the FFI seems to be able to locate symbols?!?
As to a work-around for cygwin, don't ask me now.
Probably Bruno would mention libtld or some such (if tld was created specifically because of limitations or absence of dlsym), but I don't know if that's the answer, or just an answer among many others.