52

Unix/Linux 网络时间协议版本3 Network Time Protocol Version 3 (NTP) distribution for Unix systems

Received: from snow-white.ee.udel.edu by whimsy.udel.edu id aa12768;
          29 Dec 96 10:13 GMT
Received: (from rosebud@localhost)
          by cyclone.stanford.edu (8.8.4/8.8.4)
	  id CAA19857; Sun, 29 Dec 1996 02:13:21 -0800 (PST)
From: Larry Schwimmer <[e-mail]>
Message-Id: <[e-mail]>
Subject: Re: PATCH: xntp3-5.87 configure.in
To: [e-mail]
Date: Sun, 29 Dec 1996 02:13:21 -0800 (PST)
Cc: [e-mail]
In-Reply-To:  <[e-mail]> from "[e-mail]" at Dec 29, 96 05:00:42 am
X-Mailer: ELM [version 2.4 PL25]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

You ([e-mail]) write:
> Are you saying that under Irix-5 that gethostbyaddr() gets found in both
> libc and libnsl, and/or socket() gets found in both libraries?

	Yes.  libsocket and libnsl contain the SVR4 tli libraries; you
do not need them for the BSD socket interface.  There are two fatal
problems with using libnsl and libsocket:

1) In IRIX 5.2, the libraries are buggy.  Programs using socket will
   not work.

2) In IRIX 5.3, the libraries are optional.  Programs linked against
   the libraries will work, but will only work if the system has them
   installed.  Since the default configuration does not, most systems
   will not be able to run the binaries if they are linked against
   them.  This makes them useless for a campus binary distribution.

The only platform I've seen which needs it is Solaris, which emulates
the socket calls in the libraries.  Of course, Solaris is also the
only system I have seen which allows any user to drop the network
interface because it does the socket operations in the user space.
(-: Hopefully 2.6 will fix that.  (There's a few other pure SVR4
systems which need it, but IRIX isn't one of them.

> Also, I noticed your patch changes what gets looked for in -lsocket from
> socket() to connect(), and I was wondering why you made this change.

	That's my standard patch.  It doesn't really matter which
of the functions you look for; they do the same thing.  This problem
is sufficiently common that I have a standard template for it.  (I've
also suggested that the autoconf folks make it a macro, but nothing
has come of that yet.)

> Larry> Since these programs are administrative and usually require root,
> Larry> it seems appropriate to use sbin, instead.
> 
> I tried this already, and Dave wants the programs installed in their
> "traditional" places.

	We have differing views of "traditional", but no problem.
I'll use --bindir='${prefix}/sbin'.  Just thought I'd suggest it.

			yours,
				Larry