home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / unix / bsd / 5585 < prev    next >
Encoding:
Internet Message Format  |  1992-09-11  |  3.4 KB
  1. Path: sparky!uunet!usc!sol.ctr.columbia.edu!ira.uka.de!math.fu-berlin.de!unidui!du9ds3!veit
  2. From: veit@du9ds3.uni-duisburg.de (Holger Veit)
  3. Newsgroups: comp.unix.bsd
  4. Subject: Re: Shared Libs for X11?, was Re: 386bsd -- The New Newsgroup
  5. Date: 12 Sep 92 09:48:11 GMT
  6. Organization: Uni-Duisburg FB9 Datenverarbeitung
  7. Lines: 49
  8. Message-ID: <veit.716291291@du9ds3>
  9. References: <18iprpINNg6e@agate.berkeley.edu> <1992Sep8.200625.2894@socrates.umd.edu> <veit.716026274@du9ds3> <18lkkkINN14d@agate.berkeley.edu> <veit.716107923@du9ds3> <7dnL02y821gh01@JUTS.ccc.amdahl.com>
  10. Reply-To: veit@du9ds3.uni-duisburg.de
  11. NNTP-Posting-Host: du9ds3.uni-duisburg.de
  12. Keywords: shared libraries X X11
  13.  
  14. In <7dnL02y821gh01@JUTS.ccc.amdahl.com> gab10@griffincd.amdahl.com (Gary A Browning) writes:
  15. >In article <veit.716107923@du9ds3>, veit@du9ds3.uni-duisburg.de (Holger
  16. >Veit) writes:
  17. [...]
  18. >I just finished installing X and noticed that most binaries are several times
  19. >larger than expected due to the lack of shared libraries.  I caught an article
  20. >posted here a few days back that quickly described the SysVr3 approach of using
  21. >fixed addresses for the libraries and the Sun/SysVr4 approach of using position
  22. >independent code.
  23.  
  24. >I tend to dislike the SysVr3 method since I got the impression that the source
  25. >code had to be written differently (though I am not sure why).  I also noted
  26. >that the GCC-2.2.2 compiler I just got compiled can produce PIC code which
  27. >would be one of the major hurdles for the SysVr4 method.
  28.  
  29. I don't like the fixed-address idea either, since it causes trouble with
  30. applications that rely on the addresses. If someone wants to have some special 
  31. library as shared he has to allocate some address for it. This will make this
  32. space unavailable for others who wanted to use the same address and will cause
  33. complex incompatibilities. It is, however, very simple to implement, and does
  34. work if there is the intent to have one (forever fixed) set of standard
  35. shared libraries. I looked at the Linux code and found it done exactly this
  36. way, and it is recommended there to relink the object files on every new 
  37. system.
  38.  
  39. My actual preference is the following system:
  40. Link an application with a special "stub library" that has undefined references
  41. to special "shared" code and data segments outside the standard _TEXT, _DATA
  42. and _BSS. There is a configurable shared library server that is loaded into
  43. memory at boot time (demand paging, of course) which has a symbol table in
  44. memory which contains the public references (Jump insn's) to the real
  45. libraries. The library server containing the library code is built for the 
  46. shared data/text area. The program loader (kern_execve) resolves the lib
  47. references to the shared area, and makes the program's shared data segment 
  48. copy-on-write so that it does not influence the memory of the library server.
  49. This dynamic linking does rely on the existance of a symbol table at some
  50. known location, but not on the number, the size, and the location of the
  51. shared modules.
  52.  
  53. Unfortunately, I'm currently not so deep inside the vm code of 386bsd, to
  54. decide whether this can be done in reasonable time, but I am willing
  55. to discuss about this and offer my help with implementation.
  56.  
  57. Holger
  58. -- 
  59. |  |   / Dr. Holger Veit         | INTERNET: veit@du9ds3.uni-duisburg.de
  60. |__|  /  University of Duisburg  | BITNET: veit%du9ds3.uni-duisburg.de@UNIDO
  61. |  | /   Dept. of Electr. Eng.   | "No, my programs are not BUGGY, these are
  62. |  |/    Inst. f. Dataprocessing |          just unexpected FEATURES"
  63.