scott@talarian.UUCP (Scott Weitzenkamp) (05/12/89)
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? -- Scott Weitzenkamp UUCP: uunet!talarian!scott Talarian Corporation ARPA: farmie@portia.stanford.edu "Welcome to the late show, starring NULL and void" -- Men At Work
tale@pawl.rpi.edu (David C Lawrence) (05/12/89)
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. 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. Dave -- tale@rpitsmts.bitnet, tale%mts@itsgw.rpi.edu, tale@pawl.rpi.edu
pinkas@hobbit.intel.com (Israel Pinkas ~) (05/13/89)
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? This is because unexec() does not know how to dump executables that were dynamically linked. James Turner (of Daisy) and I spent a lot of time bashing on this one, since we had early releases of SunOS 4.0 on Sun 386i's. (We were both field test sites.) The problem that I had was that there was no predictable way to determine whether the memory image had been dynamically linked. (Nothing documented, that is.) Eventually, I gave up on this, since it really didn't matter to me all that much. I don't know much about SysV, but I suspect that there should be a way. If nothing else works, you can always list the library name on the command line instead of -l<lib>. Remember to add /usr/lib/libc.a, or whatever it is on your machine, at the end of the command line if your machine has a dynamic version of libc. -Israel Pinkas -- -------------------------------------- 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
mac@mrk.ardent.com (Michael McNamara) (05/13/89)
In article <TALE.89May12023656@imagine.pawl.rpi.edu> 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. can be done. | |b) loadup is slower (often times perceptibly, not just some sort of |unnoticeable benchmark thing) when using shared libraries. not really. | |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. | |Dave |-- | tale@rpitsmts.bitnet, tale%mts@itsgw.rpi.edu, tale@pawl.rpi.edu Yes gnu-emacs can be compiled with and using shared libraries on system V. I did the port for the cydra 5 (when cydrome was still in business). The real reason GNU-emacs is distributed with -Bstatic on Sun 4.0 is because no one wanted to fix unexec to understand shared libraries. However, it is definatly possible to make unexec work with shared libraries. It is also possible to work around unexec in another way: David Robinson, at NASA Ames, has distributed diffs for gnu-emacs that: "Below are the diffs to 18.53 to implent GNU emacs under SunOS 4.0 using mmap() instead of unexec() and to also allow for shared libraries. A couple of installation notes, after temacs finishes preloading the lisp code it dumps the output into "xemacs.map" in the current directory. This file must be renamed to PATH_EXEC/emacs.map for normal use. If you wish to test the code out without moving the map file you can run "xemacs -map xemacs.map" for testing. Included in diff format are two new files, s-sunos4map.h and sunmap.c, if you are using "patch" they should be extracted with no problem. If you don't have patch (hard to believe) you can simply cut and paste them." You should send mail to David, as he has been working on this and I am sure has newer versions that what I have. He can be reached at: david@ames.arc.nasa.gov -mac _________________ Michael McNamara mac@ardent.com
david@elroy.Jpl.Nasa.Gov (David Robinson) (05/13/89)
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 have implemented a version of GNU emacs that uses shared libraries. The reason it didn't before was that emacs calls unexec() to save the data segment and bss segment, in these segments are information about where libraries are mmap'd in if you compile it with shared libraries. This information is not always the same and will definately differ on different machines. There are other problems as well. My version that uses shared libraries does so by writing out the data and bss segments to a file and mmap'ing it in upon execution. This file is mmap'd in as a copy-on-write segment so that only the pages that are changed will be copied and the rest shared. This should reduce the amount of physical memory needed when more than one copy is running and help out Suns with limited memory. I will be sending the patches to implement this to GNU as soon as I get them upgraded to the latest version of emacs. -- David Robinson elroy!david@csvax.caltech.edu ARPA david@elroy.jpl.nasa.gov ARPA {cit-vax,ames}!elroy!david UUCP Disclaimer: No one listens to me anyway!
gandalf@csli.Stanford.EDU (Juergen Wagner) (05/13/89)
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? The main reason is the way in which GNUemacs binaries are created: you start an "empty" Emacs which loads all necessary files, and then a core image of Emacs with preloaded files is created. This core image is converted to an executable program, and that's what you fire up as GNUEmacs. The problem with this process is that if you save the core image, all routines have to be resolved, i.e. the resulting image will not support dynamic linking. [I haven't built Emacs in a while, so things might have changed.] -- Juergen Wagner gandalf@csli.stanford.edu wagner@arisia.xerox.com
guy@auspex.auspex.com (Guy Harris) (05/13/89)
>I don't know much about SysV, but I suspect that there should be a way. If >nothing else works, you can always list the library name on the command >line instead of -l<lib>. Remember to add /usr/lib/libc.a, or whatever it >is on your machine, at the end of the command line if your machine has a >dynamic version of libc. I seem to remember something that indicated that with S5R3 shared libraries you had to explicitly tell "cc" to link with shared libraries; you'd have to do "cc ... -lc_s" to link with the shared C library. (S5R4 shared libraries will probably bear a startling resemblance to SunOS 4.x shared libraries....)
mike@thor.acc.stolaf.edu (Mike Haertel) (05/13/89)
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? It is very hard to make a program that has the capability of `undumping' itself (i.e., creating a new executable file which when started will restore the current state of the program) work with most shared library implementations. The problem is that the shared library generally has its own separate `data segment' which is obtained from the library on program startup, not from the executable file. The library's data segment generally contains interesting things such as the state of the I/O library and the memory allocator, stuff that you need to preserve if you're going to undump. It's certainly possible to do such an undump, and I can also visualize various shared library implementations that would make it straightforward, but they would probably less efficient in the general case. On, say, a Sunos 4 machine, the library code probably comprises less than 40K of the emacs executable anyway. It just isn't worth the effort. -- Mike Haertel <mike@stolaf.edu> main() ??< printf("hello, world??/n"); ??>
david@elroy.Jpl.Nasa.Gov (David Robinson) (05/14/89)
In article <6443@ardent.UUCP>, mac@mrk.ardent.com (Michael McNamara) writes: > It is also possible to work around unexec in > another way: David Robinson, at NASA Ames, has distributed diffs for ^^^^ JPL > gnu-emacs that: > > You should send mail to David, as he has been working on this > and I am sure has newer versions that what I have. Yes there are, I have sent them off to GNU but if there is a large cry for them now I can either mail or post it. > > He can be reached at: david@ames.arc.nasa.gov ^^^^^^^^^^^^^^^^^ Right agency wrong branch : david@elroy.jpl.nasa.gov -- David Robinson elroy!david@csvax.caltech.edu ARPA david@elroy.jpl.nasa.gov ARPA {cit-vax,ames}!elroy!david UUCP Disclaimer: No one listens to me anyway!
pinkas@hobbit.intel.com (Israel Pinkas ~) (05/15/89)
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
jr@bbn.com (John Robinson) (05/16/89)
In article <PINKAS.89May14180259@hobbit.intel.com>, pinkas@hobbit (Israel Pinkas ~) writes: >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. This depends on your configuration. If your swap device is remote via ND or NFS, swapping a page results on two network accesses. And ND is more costly than NFS to boot. >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. I don't think you can do much better than this with a diskless node. To minimize your exposure, your executables and swap area should be provided by the same server. I don't know whether NFS or ND behaves worse when the server croaks. >2) If the image is deleted, everything goes haywire. Whoa. My understanding has always been that you can unlink a file, but its inode stays around until every open FD on it is closed. You are implying that NFS breaks this behavior? Seems to me that Unix would have a hard time living with this change. >(I didn't think that anybody would >leave an Emacs process around for more than a week, but guess what?) Sho nuff. Do it all the time. -- /jr jr@bbn.com or bbn!jr C'mon big money!
meissner@tiktok.dg.com (Michael Meissner) (05/17/89)
In article <TALE.89May12023656@imagine.pawl.rpi.edu> 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?
jr@bbn.com (John Robinson) (05/18/89)
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!