Xref: utzoo comp.emacs:6067 comp.unix.questions:13615 gnu.emacs:889 Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!apple!oliveb!mipos3!pinkas From: pinkas@hobbit.intel.com (Israel Pinkas ~) Newsgroups: comp.emacs,comp.unix.questions,gnu.emacs Subject: Re: Does GNU emacs ever use shared libraries? Message-ID: Date: 15 May 89 01:02:59 GMT References: <152@talarian.UUCP> Sender: news@mipos3.intel.com Distribution: usa Organization: Corporate CAD, INTeL Corporation, Santa Clara, CA Lines: 42 In-reply-to: scott@talarian.UUCP's message of 12 May 89 05:28:45 GMT 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? Does System V have an option > like -Bstatic to prevent the use of shared libraries? I posted about this before, but I realized that there was one more thing to consider. Efficiency. SunOS 4.0 executables do not swap text pages by default (-z flag to ld). They are released from memory and marked as not present. If needed again, they are loaded from the disk image. If the original image is on an NFS mounted partition, every page fault results in an NFS access. This hurts performance on large processes. (We improved performace on our X10 server by linking with -n by 100%.) Two other problems with this demand paging are: 1) If the file server becomes unavailable (crashes, times out, etc.) the page fault can fail and the process can hang. The network is flooded with NFS requests, which slows down everybody. 2) If the image is deleted, everything goes haywire. This can happen with any type of demand paging, but the type in SunOS 4.0 just exacerbates the problem, becaus the same page can be loaded many times. (I know, this is stupid, but it happens occasionally. I didn't think that anybody would leave an Emacs process around for more than a week, but guess what?) The above are both problems with NFS, but dynamic libraries just add to the confusion. -Israel -- -------------------------------------- Disclaimer: The above are my personal opinions, and in no way represent the opinions of Intel Corporation. In no way should the above be taken to be a statement of Intel. UUCP: {amdcad,decwrl,hplabs,oliveb,pur-ee,qantel}!intelca!mipos3!cadev4!pinkas ARPA: pinkas%cadev4.intel.com@relay.cs.net CSNET: pinkas@cadev4.intel.com