Xref: utzoo comp.emacs:6080 comp.unix.questions:13639 Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!mcnc!rti!xyzzy!tiktok!meissner From: meissner@tiktok.dg.com (Michael Meissner) Newsgroups: comp.emacs,comp.unix.questions Subject: Re: Does GNU emacs ever use shared libraries? Message-ID: <6006@xyzzy.UUCP> Date: 16 May 89 17:10:16 GMT References: <152@talarian.UUCP> Sender: usenet@xyzzy.UUCP Reply-To: meissner@tiktok.UUCP (Michael Meissner) Distribution: usa Organization: Data General (Languages @ Research Triangle Park, NC.) Lines: 73 In article tale@pawl.rpi.edu writes: | In article <152@talarian.UUCP> scott@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@dg-rtp.DG.COM faster, when would we Old Internet: meissner%dg-rtp.DG.COM@relay.cs.net have time for netnews?