Does GNU emacs ever use shared libraries?

[John Robinson]

In article <6006 at xyzzy.UUCP>, meissner at tiktok (Michael Meissner) writes:

...A lucid discussion of the issues of GNU emacs vs shared libraries
(many thanks!)... 

>The building of the xemacs phase is where most the assumptions about
>how the library interacts with GNU are made, and is also the hairest
>place in general for porting GNU emacs to a new system.  There is an
>option when building GNU emacs not to build xemacs this way, but
>enabling the option means that EVERY time you start emacs, it must
>reload the lisp files.  This takes ~5 minutes on a loaded .5 Mips
>machine.
>
>Depending on how shared libraries are implemented on the Sun, garbage
>collection (another system dependent area) may be affected as well by
>shared libraries.
>
>Until you fully understand what is going on in src/alloc.c and
>src/unexec.c, and how it might interact with shared libraries, it's
>probably best not to even think about shared libraries.  I don't mean
>to be so negative about doing the port, but the GNU emacs internals
>are VERY tricky, and the assumptions made are not always clear.

It struck me that the way to build emacs is to make the compiled,
loaded elisp into a shared library.  Can anyone comment on the
feasibliity of this?  It seems to address the need that emacs' loadup
phase addresses, and by definition is the "right" way to do things in
SunOS 4 and other shared-library universes.  Since this stuff is by
definition non-portable, is a shared-library approach better than an
unexec approach in jamming one less unportable feature into one
executable?  I realize that it may not have the speed of an unshared
unexec'd emacs in many cases.

I wonder if GNU's not Unix will have shared libraries...
--
/jr
jr at bbn.com or bbn!jr
C'mon big money!