Re: Need internal help please (dynamic loading support)
On Wed, Sep 09, 1998 at 02:10:36PM -0500, William M. Perry wrote:
> a) Functions for loading and unloading DLLs.
This is all in sysdll.[ch] right now - it should work on just about all
known unix operating systems, as well as windows.
Well kinda. The functions for doing the slopen() and dlsym() stuff are in
sysdll. This is the lowest level. There needs to be a higher level layer
which will:
1) Find the .so
2) Attempt to dlopen() it
3) Verify that the correct symbols appear in it (i.e. its a valid .so)
4) Initialize the .so.
Some of this is already done in dll.c, but as I stated in my previous
message, there are different (perhaps even better) ways of doing this,
and that was the way I implemented it in CEmacs (thats what I originally
called my patches and files - an abbreviation for CE-Emacs, or C-Extensible
Emacs).
> b) Function for listing loaded DLLs and their versions
Not sure if we really need this or not, but it could be handy for
debugging stuff. Save the situation of 'I just changed that .el file, why
aren't I seeing my changes'. :)
It is useful to know so that you can unload
a .so to replace it with a
new version. Unloading is possible, but can be tricky. This is definately
the last thing to do, as there are more important issues to worry about.
> c) A sensible and similar (to the internals) API, which is
partly documented
> already.
> d) Required patches for the Makefile to propperly support dynamic loading.
That should be taken care of already as well. Just need to add some
stuff for linux and HP/UX to export symbols to the loaded modules. I
thought I had done that already, but it seems to be missing from the CVS
versions.
Any any other OS that supports dlopen() and friends, like (ahem) SCO :-)
Basically, the OS header files should set macros which will be used
in creating the scripts / Makefile. For example, both SCO and Linux require
a -Wl,-Bexport flag on the temacs link line to get the internal symbols to
be exported for use in .so's. Of course, that exports ALL symbols, resulting
in the same linkage restrictions that any .o would have. We have the option
(and may well want to) to restrict which symbols are exported. I.e. - for
dynamic modules, the only functions and variables you can ever use are
foo, bar and baz. This is most probably more work than its worth, and no-one
seems to do it. Perl, Zsh, Python, all of them simply export everything.
I had planned on doing something similar to Perl's Makefile.PL
stuff.
You would write a Makefile.el script describing your targets and things
like that, and:
xemacs -batch -e "(require 'makemaker)" -f make-makefile Makefile.el
*shudder* - I guess some people things its neato but I personally think
that mechanism sucks, but I'll bow to popular opinion on its merits :-)
It does have merits, but I think its a little over-engineered, and it
will require potential developers to learn Lisp for the makefile, and
having loaded .so's is worthwhile becuase so few people want to learn Lisp
if they can do it in C!!! Perhaps a compromise of a makefile template
that requires less Lisp and more familiar Makefile teritory would be in order.
We don't want to be too quick about it, but this is something
I
definitely want to see in 21.x (x > 0). As always, correctness counts more
than quickness. :) I'm trying to free up more time for hacking on XEmacs
and Emacs, but time will tell.
Well this is not rocket science, and can be done
both correctly and
quickly. Complete documentation can take longer, but at least the actual
infrastructure will be in place. I think we'll find that if we have a
working model and a few samples, that that will suffice for most people
who are inclined to write extension packages in C. We're all hackers, right?!
--
J. Kean Johnston | "Truth and beauty, beauty and truth. This is all we know,
Engineer, SPG | and all we need ever know." -- John Keats, Endymion
Santa Cruz, CA +----------------------------------------------------------
Tel: 408-427-7569 Fax: 408-429-1887 E-mail: jkj(a)sco.com