Xref: utzoo comp.emacs:6093 comp.unix.questions:13665 Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!bloom-beacon!apple!bbn!jr@bbn.com From: jr@bbn.com (John Robinson) Newsgroups: comp.emacs,comp.unix.questions Subject: Re: Does GNU emacs ever use shared libraries? Message-ID: <40094@bbn.COM> Date: 17 May 89 18:56:05 GMT References: <152@talarian.UUCP> <6006@xyzzy.UUCP> Sender: news@bbn.COM Reply-To: jr@bbn.com (John Robinson) Followup-To: comp.emacs Distribution: usa Organization: BBN Systems and Technologies Corporation, Cambridge MA Lines: 38 In-reply-to: meissner@tiktok.dg.com (Michael Meissner) In article <6006@xyzzy.UUCP>, meissner@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@bbn.com or bbn!jr C'mon big money!