On Tue, 8 Feb 2000, Greg A. Woods wrote:

> > > Of course, a quick grep of libwrap.so shows that these refs are in the
> > > library.
> >
> > 	Certain code in the library depends on those variables being
> > 	defined by the calling program (which is lightly bogus),
> 
> It's definitely not "bogus" -- it is a somewhat uncommon programming
> practice when used with libraries that are later decided to be made into
> shared libraries, but it's not bogus.  If it is "bogus" only when used
> with shared libraries then the fault lies with the decision to make
> libwrap into a shared library, not with a perfectly valid programming
> practice.
> 
	Apologies for the ambiguity in my statement - its use in a shared
	library is lightly bogus (not incredibly, but somewhat). It would
	be much better to pass in pointers to {allow,deny}_severity as
	needed.

> In every other sane shared-library system I've ever used, including the
> venerable SunOS-4 ones that NetBSD's are derived from, the compile-time
> linker chokes immediately when a library, shared or otherwise, makes an
> unresolved reference.  In no case should the failure ever have to wait
> for the run-time linker to find it.  If this means bringing back the
> lib*.sa files then so be it.
> 
	Just to clarify - the problem is that code in the shared library
	which is not called referenced {allow,deny}_severity?

		David/absolute