"J. Kean Johnston" <jkj(a)sco.com> writes:
> 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).
Do all platforms have the idea of an 'initialization' function for dynamic
libraries? I know most elf systems do with _init and _fini, and windows
has DllMain. It would be nice to just hook into that for doing the
DEFSUBR() and things instead of having the somewhat arbitrary
emacs_initializate function name.
> > > 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 must have sanitized my comments about SCO in the source :). I really
dislike the fact that _dlopen is the symbol in libc, and dlfcn.h #defines
dlopen _dlopen. Really makes doing the autoconf stuff a little ickier.
:)
All the stuff in sysdll works under SCO OpenServer 5.x, other than the
exporting all symbols stuff. We could get around that by putting some of
the core functionality of XEmacs in a libxemacs.so or something like that.
I don't know if that's worth it or not though.
I know the sysdll stuff works under:
SunOS 4.x
Solaris 2.x
BSDI 2.x, 3.x
HP/UX 9.x, 10.x
AIX 4.x (and 3.x if you install libdl.a yourself)
Digital Unix
IRIX
Linux
(Free|Open)BSD
Windows (16 & 32 bit)
SCO OpenServer
UnixWare
The autoconf stuff needs a little hacking for some of the XEmacs
specifics (-Bexport, etc.) but not much.
> > 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.
Right now, all the macros relating to this are stored in the XEmacs
configure output, which you can access via config-value-hash-table. A real
small function in aclocal.m4 lets you get to those values again. A sample
from modules/configure.in is:
XE_EMACS
XE_CONFIG_VALUE(dll_cflags dll_ld dll_lflags dll_oflags CFLAGS CC DEFS INSTALL top_srcdir blddir)
AC_SUBST(dll_cflags)
AC_SUBST(dll_oflags)
AC_SUBST(dll_lflags)
AC_SUBST(dll_ld)
AC_SUBST(top_srcdir)
AC_SUBST(blddir)
If we stick to this way, _everything_ can just use autoconf for
configuration.
They are going to have to know a fair bit about the internals of
XEmacs or Emacs before they can write one of these anyway. :) But yes, I
much prefer autoconf to Makefile.PL or Makefile.el crap. That's why I've
made Emacs/W3 use autoconf for everything.
> > 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?!
The basic stuff was very easy to put in - I've been doing some variant of
it under unix and windows for the past 4 years for various projects, so it
gets to be old hat after a while. That's when I got tired and distilled it
down into sysdll.[ch] and some standard autoconf macros you can throw into
just about any project.
The basic interface is fairly solid right now, it just needs polishing.
I can probably free up a little bit of time to help finish this up. It's
one of the things I _really_ want XEmacs and Emacs to have. Then I can try
to get the parser and some of the network shit for Emacs/W3 down into C
where performance won't suck.
-Bill P.
