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
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"
Newsgroups: comp.unix.bsd