Subject: Re: CVS commit: pkgsrc
To: Chris G. Demetriou <cgd@sibyte.com>
From: Greg A. Woods <woods@weird.com>
List: source-changes
Date: 09/28/2000 20:25:27
[ On , September 28, 2000 at 09:00:20 (-0700), Chris G. Demetriou wrote: ]
> Subject: Re: CVS commit: pkgsrc
>
> -lbar may be extraneous at link time, indeed may be _entirely empty_
> at link time and provide nothing for the program to use.
> 
> however, it still has to be loaded and checked at run-time, because
> the version available at run-time may provide some of the symbols also
> provided by -lbaz and -lc.
> 
> in other words, the version of a library available at run time may be
> used to override some symbols in the later libraries.

That might be true in the current implementation, but that's bogus.
I.e. it's the wrong way of achieving the desired result.

There's no valid excuse for using shared libraries in this way and it
totally breaks the principle of least astonishment (i.e. the compiler
now suddenly creates binaries that can never work despite the fact that
those binaries previously worked just fine before shared libraries were
swapped in underneath everything with dynamic binaries as the new
default target).  I don't know how many times I've tripped over this
"bug" in porting software to systems with dynamic libraries, but it's
certainly been "lots" of times and it's often been very difficult to
rework some arcane build system just to avoid this nonsense.

If at runtime someone wants to override the symbols in a later library
then they're prefectly capable of replacing that library with a new
version using a new minor number.  If they can't do that then by
definition they do not have enough information to safely override any
symbol in the existing libraries.

Talk about handing out more than enough rope to hang all the users, the
developers, and the admins all at once!

Dynamic loading is one thing, but fully dynamic linking and symbol
resolution is just plain bad juju!  Systems that are designed to work
that way properly are very different in nature and there's no dynamic
loader process going around messing things up.  I want a load map that
will at least tell which library every dynamic symbol will be found in
and I want a warning if any symbol is not found in the right library at
run time.  If I'm going to use a dynamic loader then I want it to do its
part in upholding the API contract between me as a developer and the
library provider -- allowing things to change almost arbitrarily after
the fact is just no kosher.

> Also, even though no functions or data items in a library are directly
> referenced, the side-effects of its loading may be important.
> (e.g. the solaris 0@0 shared library).

Side effects like that are REALLY bogus!  Talk about doing things the
wrong way!  This is the kind of thing that makes software developers who
are trying to build clean solid reliable systems with guaranteed
repeatability shake their fists with rage at the inventors of dynamic
libraries!

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>