Subject: Re: static vs. dynamic runtime linking, esp. for citrus (was PAM and su -K)
To: David Laight <david@l8s.co.uk>
From: Greg A. Woods <woods@weird.com>
List: tech-userlevel
Date: 01/29/2005 16:30:25
[ On Friday, January 28, 2005 at 20:25:28 (+0000), David Laight wrote: ]
> Subject: Re: static vs. dynamic runtime linking, esp. for citrus (was PAM and su -K)
>
> I remember the implication of fixing a file locking problem in the
> utmp file handling code, since this wasn't part of the dynamic libc [1]
> all the customer (and 3rd party) apps that used the function had to
> be discovered and relinked.  No mean feat.

Indeed it was no easy problem in the good old days, but we are not
running SunOS, nor anything else proprietary -- we are running NetBSD
and most of us who use NetBSD in production (no doubt the vast majority
of us) are also using open source applications as well.


> [1] A misguided attempt at sparc ABI conformance meant that some libc
> functions were dynamic (those in the ABI) and others static.

Indeed this makes your example even more bogus since in the NetBSD world
any proprietary third party applications can still be fully dynamic
linked and thus will _NOT_ have to be re-linked and re-distributed by
all the third-party vendors to all their NetBSD users should any such
problem be fixed in the future.

Static linking of the base system, or part of it, and of open source
applications, AT THE USERS CHOICE, does not in any way force third-party
vendors to static link their proprietary applications.  (And I'm sure
any that do so regardless will be well aware of these issues.)

I.e. you're spreading F.U.D.

-- 
						Greg A. Woods

H:+1 416 218-0098  W:+1 416 489-5852 x122  VE3TCP  RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com>          Secrets of the Weird <woods@weird.com>