Does GNU emacs ever use shared libraries?

[Michael Meissner]

In article <TALE.89May12023656 at imagine.pawl.rpi.edu> tale at pawl.rpi.edu writes:
| In article <152 at talarian.UUCP> scott at talarian.UUCP (Scott Weitzenkamp) writes:
| >   I noticed that on SunOS 4.0, GNU emacs uses the -Bstatic flag to cc
| > to prevent the use of shared libraries.  Does GNU emacs ever use 
| > shared libraries?  If not, why not? 
| 
| Two reasons that I can think of:
| 
| a) debugging is hell on something link edited with shared libraries.
| 
| b) loadup is slower (often times perceptibly, not just some sort of
| unnoticeable benchmark thing) when using shared libraries.

There are three other possible reasons:

c) RMS and/or other people at FSF may not run SunOS 4.00 (which
introduced shared libraries to the sun world);

d) Shared libraries interfere with the way GNU emacs' internals;

e) nobody has done the work and submitted it to the FSF.

| I am pretty certain that it _can_ be compiled with the libraries (ie,
| what should prevent it, code-wise), but it isn't.  The primary
| argument for using them is to cut down on size of the application, but
| the subsequent loss of debugging power and load-up time outweighs that
| consideration as long as you have the space on your system.

After hacking on GNU emacs, including doing half of the port to the
Data General MV series, I can state that GNU emacs' internals are
probably not condusive to most people's shared libraries.  In case you
are curious, the way GNU is normally built is as follows:

	You compile the C portion of GNU.

	You link these together to provide temacs.

	Temacs is run and loads in all of the standard lisp files into
	it's address space.

	Temacs then builds an executable 'xemacs', which contains the
	shared text code from temacs, and initializes the data segment
	with the current contents of memory after doing the load.  On
	most systems, it also moves the 'pure' array (which holds the
	lisp code read in) into the text segment, so that multiple
	emacs' will share this.

	The installer then renames xemacs, and installs it whereever
	s/he desires.

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.


--
Michael Meissner, Data General.
Uucp:		...!mcnc!rti!xyzzy!meissner		If compiles were much
Internet:	meissner at dg-rtp.DG.COM			faster, when would we
Old Internet:	meissner%dg-rtp.DG.COM at relay.cs.net	have time for netnews?