Return to BSD News archive
Path: sserve!manuel!munnari.oz.au!uunet!usc!sol.ctr.columbia.edu!ira.uka.de!math.fu-berlin.de!unidui!du9ds3!veit From: veit@du9ds3.uni-duisburg.de (Holger Veit) Newsgroups: comp.unix.bsd Subject: Re: Shared Libs for X11?, was Re: 386bsd -- The New Newsgroup Date: 12 Sep 92 09:48:11 GMT Organization: Uni-Duisburg FB9 Datenverarbeitung Lines: 49 Message-ID: <veit.716291291@du9ds3> 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> Reply-To: veit@du9ds3.uni-duisburg.de NNTP-Posting-Host: du9ds3.uni-duisburg.de Keywords: shared libraries X X11 In <7dnL02y821gh01@JUTS.ccc.amdahl.com> gab10@griffincd.amdahl.com (Gary A Browning) writes: >In article <veit.716107923@du9ds3>, veit@du9ds3.uni-duisburg.de (Holger >Veit) writes: [...] >I just finished installing X and noticed that most binaries are several times >larger than expected due to the lack of shared libraries. I caught an article >posted here a few days back that quickly described the SysVr3 approach of using >fixed addresses for the libraries and the Sun/SysVr4 approach of using position >independent code. >I tend to dislike the SysVr3 method since I got the impression that the source >code had to be written differently (though I am not sure why). I also noted >that the GCC-2.2.2 compiler I just got compiled can produce PIC code which >would be one of the major hurdles for the SysVr4 method. I don't like the fixed-address idea either, since it causes trouble with applications that rely on the addresses. If someone wants to have some special library as shared he has to allocate some address for it. This will make this space unavailable for others who wanted to use the same address and will cause complex incompatibilities. It is, however, very simple to implement, and does work if there is the intent to have one (forever fixed) set of standard shared libraries. I looked at the Linux code and found it done exactly this way, and it is recommended there to relink the object files on every new system. My actual preference is the following system: Link an application with a special "stub library" that has undefined references to special "shared" code and data segments outside the standard _TEXT, _DATA and _BSS. There is a configurable shared library server that is loaded into memory at boot time (demand paging, of course) which has a symbol table in memory which contains the public references (Jump insn's) to the real libraries. The library server containing the library code is built for the shared data/text area. The program loader (kern_execve) resolves the lib references to the shared area, and makes the program's shared data segment copy-on-write so that it does not influence the memory of the library server. This dynamic linking does rely on the existance of a symbol table at some known location, but not on the number, the size, and the location of the shared modules. Unfortunately, I'm currently not so deep inside the vm code of 386bsd, to decide whether this can be done in reasonable time, but I am willing to discuss about this and offer my help with implementation. Holger -- | | / Dr. Holger Veit | INTERNET: veit@du9ds3.uni-duisburg.de |__| / University of Duisburg | BITNET: veit%du9ds3.uni-duisburg.de@UNIDO | | / Dept. of Electr. Eng. | "No, my programs are not BUGGY, these are | |/ Inst. f. Dataprocessing | just unexpected FEATURES"