Does GNU emacs ever use shared libraries?

[John Robinson]

In article <PINKAS.89May16141851 at hobbit.intel.com>, pinkas at hobbit (Israel Pinkas ~) writes:
>Our configuration is a "dataless workstation model".  Swap space (anywhere
>from 16M to 100M) is local.  The kernel, and most of the "basic" binaries
>distributed are local.  User directories, /usr/local, etc. are NFS mounted.
>We run primarily on Suns and uVaxen.
>
>With this configuration in mind, my orginal statement(s) makes more sense.

Indeed.  Wish we had so many disks...

>What we have done is implement a methodology.  Instead of removing the
>file, rename it.  (i.e. emacs -> .emacs.orig)  The delete it a week later.

The method we have adopted here for emacs may be of interest to the net.

For most users, issuing the command `emacs' at a shell invokes
/usr/local/bin/emacs.  This file is a symbolic link to
/usr/local/emacs/dist/xemacs.  In /usr/local/emacs, dist itself is a
symbolic link to, for example, dist-18.53.  /usr/local/emacs/src, in
turn, is a sym link to dist/src, and ditto for man, info, lisp, etc,
etc.  In a NFS environment, we put the less-used subdirectories (src,
man, info, cpp) on a subset of the file servers, with links from the
other servers at the dist-XX.XX level to preserve version consistency.
(This may fool you if you are navigating within the subdirectories
with cd ../foo).  lisp and etc we copy to each file server.

In dist-18.53/, xemacs is a hard link to src/emacs-18.53.X, where X is
the current minor version number.  [For the less fortunate file
servers, we cp -p the new executables from the server with all of
src/; this could lead to stale file handles unless you mv the older
minor version out of the way].  I find this scheme pretty workable,
for the following reasons:

1.  The dist-XX.XX naming is consistent with emacs as distributed,
especially diff files.  Makes patching easier.

2.  A major release is accomplished simply by changing the dist
symlink in /usr/local/emacs to the right new major version number.
Although this makes the lisp files inconsistent with the executable,
we haven't found this to be a major problem.

3.  A minor release is accomplished by unlinking dist-XX.XX/xemacs and
relinking it to (the newer) src/xemacs.  Since the old version stays
around in src/ with its explicit version name (emacs-XX.XX.X), we
avoid stale file handles.

4.  Once a version is superseded, we wait a week or more before
removing the executable (or distribution) altogether.

5.  Note that DOC files often are the same between minor version
numbers.  You can save space by hard-linking them together.  Also, we
have to hard-link DOC files between the etc/ directories of the
various dist-XX.XX trees to smooth major version transitions.
(Generally, there will only be at most two major version active at a
time.)

We don't try to extend this across architectures (yet).  We are sort
of toying with that problem for TeX...

Note: I don't read comp.unix (whither followups), so please cc me on
any interesting replies...thanks.
--
/jr
jr at bbn.com or bbn!jr
C'mon big money!