Return to BSD News archive
Newsgroups: comp.unix.bsd
Path: sserve!manuel.anu.edu.au!munnari.oz.au!network.ucsd.edu!usc!sol.ctr.columbia.edu!eff!news.byu.edu!ux1!fcom.cc.utah.edu!cs.weber.edu!terry
From: terry@cs.weber.edu (A Wizard of Earth C)
Subject: Re: Questions on Joerg Shared lib
Message-ID: <1992Dec9.172904.13771@fcom.cc.utah.edu>
Sender: news@fcom.cc.utah.edu
Organization: Weber State University (Ogden, UT)
References: <1992Dec2.043206.23671@ntuix.ntu.ac.sg>
Date: Wed, 9 Dec 92 17:29:04 GMT
Lines: 74
In article <1992Dec2.043206.23671@ntuix.ntu.ac.sg> othman@ntrc25.ntrc.ntu.ac.sg (othman (EEE/Div 4)) writes:
>
>1) What are the limitations of this shared lib, apart from having to convert
>the current libs.
i) Reduced virtual address space for all programs, since all libs
are relocated to fixed addresses, thus requring the space for
each lib to be subtracted from all programs, even if they do
not use the lib in question.
ii) No support for versioning ...ie: I can not specify major
version number changes to refer to interface changes. Thus
I am required to recompile on major revs to libraries.
iii) Centralized assignment of library address ranges requires a
central authority with time and inclination to do the job.
iv) Fixed library address ranges limit growth of libraries to the
memory space between their start address and the start address
of the next library in sequence.
v) No implicit support for shared memory, loadable kernel modules,
loadable kernel extensions, dynamic object loading (linking)
like you'd need in a decent non-interpretive LISP, etc., etc.
>2) How does the conversion work? Do we have to recompile all the libs? From
>the first analysis of the Makefiles, it appears as though it does not have to?
i) Re-make all libs. Recompile all apps using the "shared" libs.
ii) Well, type "make" anyway. This will probably result in the object
files being regenerated. I suppose you could make existing
libraries into "shared" libraries with a bit of conniving, but the
time spent would probably exceed recompilation time.
iii) Well... there are object and dependency assumptions which imply
a recompilation; you could probably manually do it if you wanted
to spend the time.
>3) Do I have to recompile all utilities in order to exploit this shared lib?
Yes. Definitely.
>4) Is the patches to gcc and g++ really necessary? We can use command line
>options to select alternative crt and libc, can't we?
i) Technically, no.
ii) Technically, yes, but any unresolved symbols will result in the
standard default libraries being dragged in. This prevents that.
There is also an implicit assumption that you want shared libs
to be the default. I assume that this is why the patches are
done. Besides, the options are a bit large to remember so that
you ling against the symbol table as opposed to the shared objects.
>I've deleted a lot of large sources but it is the small programs that benefit
>the most from shared libs, don't they?
With relatively small sources (relative to the size of the library they are
linked agianst) the benefits are proportionally greater. On the other hand,
any X app you are running would benefriit greatly, as would any app linked
against a huge library.
Terry Lambert
terry@icarus.weber.edu
terry_lambert@novell.com
---
Any opinions in this posting are my own and not those of my present
or previous employers.
--
-------------------------------------------------------------------------------
"I have an 8 user poetic license" - me
Get the 386bsd FAQ from agate.berkeley.edu:/pub/386BSD/386bsd-0.1/unofficial
-------------------------------------------------------------------------------