[ On Friday, April 7, 2000 at 11:51:02 (-0400), Andrew Brown wrote: ]
> Subject: Re: -lwrap and externals
>
> s/NetBSD ELF//
> 
> it's broken, period.

Well, not exactly.

>    i've seen this "broken" behavior on different
> operating systems and different platforms.  usually the program that
> doesn't define the symbols itself can do without the library (eg
> mail.local in a new sendmail release) so simply relinking without
> -lwrap is fine.

Yes, this is exactly the case.

The bug is in the compile-time link loader.  It should not be attempting
to resolve symbols found to be undefined in a library when there's been
no reason to include any objects from that library.  I.e. in this case
it should not include references to the shared libwrap.so binary in a
dynamically linked binary if the latter makes no reference to any symbol
actually defined in libwrap.

So far as I can recall this bug has been present in NetBSD (aout and ELF
variants) (and presumably other *BSDs) ever since day one.  This bug was
not present in SunOS-4.  This bug was never present in any static
linking system on any Unix or unix-like system that I'm aware of (and
I've ported software that would have tripped over this to almost every
such system that ever existed).

It is not illegal, or even unusual, for a library to reference symbols
that it expects to be defined in the calling program.  The only thing
unique about the situation with libwrap is that it's the only NetBSD
system library that does this.

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