Re: loading functions from a shared library

[Steve Kemp]

On 14 Dec 2001, Dave Love wrote:

> Yes, that's `well-known', apart from potential problems related to
> dumping.  There's a TODO entry.  I don't think it will interact with
> the GC conservative stack scanning, but that's worth considering.

  Hmm, thats someething that I'd not considered - it might not be
 an issue if the modules are never unloaded though, as they'll be
 marked in use.

> As far as I remember, we (Gerd, me and someone else who was looking at
> implementing it a year or so ago) agreed it was best to do it using
> libtool facilities in the canonical way.  I think that's better than
> following what XEmacs does, especially as I seem to remember they had
> problems and their facility is little-used.  I was unclear then
> whether what Guile and SCM's do was worth looking at -- they have
> dynamic loading, and at least used to use unexec facilities borrowed
> from Emacs, but it seemed to have gone away in Guile when I last
> looked.
>
> [This is one thing which would be substantially easier in a build
> framework that used automake and more autoconfiscation, which is the
> reason I didn't get round to implementing it.]

  Libtool is something that I've never really looked at, so that might
 change things a little bit.

  Today I got the XEmacs styled code compiled, and managed to load
 a trivial extension module working.

  I'll try to find out more about libtool soon, to see if that would
 be a better way to go.  The immediate question I'd have, though, is
 would libtool be available for all the platforms upon which Emacs
 currently runs?

  I do agree that the XEmacs facility seems to be underused though,
 the only code that I've found which uses it are the samples which
 come with the main distribution.

  I'm keen to get some form of dynamic loading inside Emacs because
 that would be a good starting point to adding some Registry, and
 COM handling abilities inside the NT Emacs port, it could also be
 used as the mechanism for introducing a FFI.

Steve
---