[ On Tuesday, February 8, 2000 at 09:42:31 (+0000), David Brownlee wrote: ]
> Subject: Re: your mail
>
> On Mon, 7 Feb 2000, Jerry Alexandratos wrote:
> >
> > I'm trying to compile exim and xinetd with tcp_wrappers support and I'm
> > running into some funky problems.  My system is a -current (1.4R)
> > compiled a few days ago.
> > 
> > With exim I get the following errors:
> >     /usr/lib/libwrap.so: undefined reference to `allow_severity'
> >     /usr/lib/libwrap.so: undefined reference to `deny_severity'
> >     collect2: ld returned 1 exit status
> >     *** Error code 1
> > 
> > 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.

> 	    and
> 	the NetBSD linker chokes if they are not (which is more bogus).

This still happens in -current?!?!?!  I'm guessing that Jerry is using
i386, which means ELF too.  If so then this is really bogus.

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.

I reported this bug a very long time ago (relatively speaking :-) and
was under the impression that I should just be patient and wait because
all would be fixed with the conversion to ELF.  I now wish I'd filed a
PR to remind me of when I'd first discovered this issue.  It is
documented in a way in PR#3522 though.

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