From: hab@engr.ucf.edu (Hubert Bahr) Subject: Re: shared libs Date: Fri, 14 Aug 1992 04:04:59 GMT
In article <1992Aug13.183740.24742@ods.com> david@ods.com (David Engel) writes:
>Owner of this machine (pmacdona@tadpole.bcsc.gov.bc.ca) 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 hab@engr.ucf.edu
PS. If I wanted to maintain a comercial product in binary form only I
would probably love jump tables.