Re: Need internal help please (dynamic loading support)
Hrvoje Niksic <hniksic(a)srce.hr> writes:
"J. Kean Johnston" <jkj(a)sco.com> writes:
> I would like to enlist the help of an XEmacs internals guru to get
> me over these hurdles, if you think this would be a worthwhile
> exercise. I already have things set up such that compiling modules
> is trivial (and will work the same way on all platforms that support
> dlopen()).
Note that you can achieve greater portability by using Bill's stuff in
sysdll.c.
I'll try to answer some of your questions.
> a) Getting DOC strings for variables defined correctly. When the .so
> is loaded in, a special function is called which does the moral
> equivalent of DEFSUBR() or DEFVAR_LISP() et al. I can see the
> variables defined but I dont know how to go about making the doc
> string visible.
The doc string is a symbol property `variable-documentation'. It can
be either a string, or a character position in the DOC file. XEmacs
itself gets the docstrings done before the dumping; look for
`make-docfile' and friends.
I was thinking of having a stub .el file be written out at build time
that would just load the foo.ell file and stick the function documentation
strings in brute force wise. This would make it so no hacking of `load'
would need to happen - it would just find the stub .el file, which would do
all the loading of the DLL, etc.
Another option is to have the module do it after it calls DEFSUBR and
friends. Stallman favors this approach.
> b) When i DEFSUBR() a function that was declared in the .so, and
try
> to execute it, I get a SIGSEGV in Fcommanp when it calls
> SUBRP(fun).
I'm not sure why that happens. Can you trace exactly where the segv
happens?
did you compile --gung-ho? I seem to remember minimal tag bits being a
requirement for the dll stuff to work.
-bill p.