[ On Wed, October 14, 1998 at 17:06:58 (-0400), Nathan Dorfman wrote: ]
> Subject: broken libwrap.so? in 1.3.2/sparc
>
> After compiling ucd-snmp 3.5.3 from -current's pkgsrc (the 1.3.2 wants
> ucd-snmp 3.5 which doesn't exist on the distribution site anymore), and
> adding --with-libwrap, I get this problem:
> 
> /usr/libexec/ld.so: Undefined symbol "_deny_severity" in snmpget:/usr/lib/libwrap.so.0.0

A similar "problem" was reported in PR#3522, and there was some
discussion of this issue on one list or another at some time too....

The problem is that libwrap expects the "calling" program to define
'deny_severity' (and 'allow_severity', the two most inappropriately
named globals in libwrap!).  I don't know if ucd-snmp acually makes use
of the libwrap functions, or not.  If not then '-lwrap' should not be
used when linking it.  If it does then it must define global variables
to satisfy the references in the library [see hosts_access(3)].

Unfortunately the NetBSD ld.so, unlike it's SunOS-4 equivalent, keeps
dependencies for variables such as this (i.e. ones referenced by a
shared library, but not defined there), regardless of whether the
"calling" program ever actually makes any calls to routines in the
library which truely reference such variables (or even regardless of
whether or not *anything* is referenced in the library).  As the closing
entry in PR#3522 says:

     One might argue that the NetBSD linker should not add dependencies to
    any command-line-specified libraries that aren't actually needed, but libwrap
    shouldn't have these declarations added.

(the latter part of that sentence referrs to the hack suggested by the
PR's author)

Indeed under SunOS-4, no dependencies for un-referenced gobals remain in
a program which does not make use of the library.

One could also argue that ld(1) should warn of unsatisfied references
from a shared library.....

-- 
							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>