[2669] in Kerberos_V5_Development
Re: -lsocket, -lnsl
daemon@ATHENA.MIT.EDU (John Hawkinson)
Sun Oct 26 13:54:17 1997
Date: Sun, 26 Oct 1997 13:54:01 -0500
To: Paul Pomes <ppomes@Qualcomm.com>
Cc: krbdev@MIT.EDU
In-Reply-To: "[2665] in Kerberos_V5_Development"
From: John Hawkinson <jhawk@MIT.EDU>
A pox upon the bind maintainers forth their lack of a decent list
of changes in their product.
| In the new version of bind (v8.x), libresolv.a has been renamed to
| libbind.a. Checks for libresolv.a should give precedence to
| libbind.a if it's in the -L search path.
I don't think this is acceptable.
If bind 8.1 is installed in a directory path that happens to be in the
library search path, it should not necessariyl override libresolv.
libbind and libresolv have different semantics. The former does DNS
exclusively and the latter may do a service switch on some
architectures. In general the typical application probably prefers to
use the operating system's service switch, unless it's running under
SunOS.
So, the mere presence of libbind in the search path doesn't mean that
everybody necessarily wants to use it, to the exclusion of libresolv.
If you want to deviate from the operating system you should have to
take special action, it shouldn't be the default. Maybe there should
be a mechanism for the administrator to say that libbind should
be preferred to libresolv -- if so, maybe that belongs in acsite.m4
somewhere.
This is essentially moot, however, as the only point where
AC_LIBRARY_NET checks for libresolv is when it has completely failed all
other choices, and is basically a corner case. I guess it could look
for libbind if it doesn't find libresolv, but I can't think of a system
where that would ever happen.
Any thoughts?
--jhawk
