NetNews Usenet Archive 1992 #18/NN_1992_18.iso/spool/comp/os/linux/8192

Internet Message Format | 1992-08-13 | 4.0 KB

Path: sparky!uunet!dtix!darwin.sura.net!cs.ucf.edu!hab
From: [e-mail] (Hubert Bahr)
Newsgroups: comp.os.linux
Subject: Re: shared libs
Message-ID: <[e-mail]>
Date: 14 Aug 92 04:04:59 GMT
References: <[e-mail]> <[e-mail]>
Sender: [e-mail] (News system)
Organization: engineering, University of Central Florida, Orlando
Lines: 75

In article <[e-mail]> [e-mail] (David Engel) writes:
>Owner of this machine ([e-mail]) wrote:
>: At last count, I understood that jump tables do nothing to solve the
>: library data problem.  Has that been solved?   If so, just adding
>: jump table support to GCC, won't solve the problem.
>
>You're right, a jump table does nothing to solve the data problem.
>What I finally did was bite the bullet and change the library source
>(there really wasn't that many changes needed) so the relevant data
>could be linked at a known location every time.  I also added padding
>to leave room for those things that might grow.
>
>: First, jump tables have a performance hit.   And using them may
>
>Yes, there is a slight performance hit but it's not even noticable
>for most programs.  One of these days, when I get the time and
>inclination, I'm going to do some more accurate benchmarking.  The
>2-4 % I measured a long time ago still seems a little high to me.
>Of course, nobody is forcing you to use the jump table libs.  If you
>need that last bit of performance, you can always use the regular
>shared libs.

Not when HJ only provides GCC only as a binary using jump tables for
it.  We are forced to use at least GCC with jump tables.

>
>: never work, since the change of one interface will screw the upgrade.
>: Worse, if an interface changes without us realizing it, then our
>: programs could just start acting strange (far worse than broken).
>
>Yes, an interface change could wreak havoc on the libraries.  However,
>in developing version 1 of the jump table libs, I learned several
>techniques to handle such changes.  Short of wholesale changes to
>the entire library, I think we can handle most changes and retain
>backward compatibility.
>
>As someone who has been using the jump table libs almost exclusively
>for four months now, I can atest that they are feasible and they do
>work.
>
>: The current implementation of shared libs has two main characteristics:
>: simple and reliable.
>
>Make that three:  simple, reliable and a pain in the *ss when it comes
>to system maintenance.  You either have to waste disk space by keeping
>multiple images of the same library lying around or you have to relink
>*everything* whenever library bugs are fixed.
>
>: Of course, I would love to be told I am wrong :-)
>
>Give them a try when H.J. releases 2.2.2d.  You might be pleasantly
>surprised.
>
>David

I for one want to know that I have an up to date source library for all
the software I use.  I also want this library compilable with the current
make files and utilities.  Yes it will take extensive work to automate
this recompile effort, but I think the dividends are multifold, 1st If
I check things when they have just been changed, the changers will probably
be more responsive to bug reports.  2  New versions of GCC and libraries
are usually to fix bugs or performance flaws.  How can I take advantage
of those changes without recompiling anyway.  3.  I can take advantage
of all information available from GDB to make the programs better.  4  I
don't introduce another level of indirection into my programs.  Frankly
I only intend to use dated binaries as a tool to reach my goal of keeping
my whole library current and buildable with current tools and sources.
In this environment I see absolutely no benefit with jump tables.  True
freedom with software is to have complete control to make desired changes
without undue suprises.

Hubert Bahr        [e-mail]

PS.  If I wanted to maintain a comercial product in binary form only I
would probably love jump tables.