Jonathan Stone wrote:

> In message <200001200145.MAA18689@balrog.supp.cpr.itg.telecom.com.au>,
> Simon Burge writes:
> 
> >Folks,
> >
> >I'm working on integrating ntp4 into NetBSD, and have come across an old
> >problem where one library module has a reference to a function that the
> >calling program is expected to define, but the program doesn't call that
> >module. 
> 
> Try asking Harlan Stenn nicely to not do that?
> 
> I told him about this problem before, and one recent ntp4 snapshot --
> 4.0.98f, i think it was -- linked cleanly into a shared
> library. Harlan is pretty good about fixing stuff, if you explain why
> its' a problem and get him to buy into a solution.  Unfortunately, to
> *keep* it working probably requires adding libtool smarts to the UMD
> ntp autconfiguration; otherwise it can break again without anyone
> noticing.

Making set_signal() take a function pointer instead of assuming the
name "input_handler" would seem to work.  I'll put something together
and send it off.

> >Two questions then:
> >
> > 1) Why do we have a libntp as a shared object (or a library at all in
> >    /usr/lib)?  The ntp distribution doesn't seem to install it, and
> >    it's not as if we get a huge saving - on an alpha:
> 
> I dont know.  There used to be a latency argument for static-linking
> (x)ntpd and running it noswap, so it'd respond faster when it got its
> periodic packets or what-have-you.

Hmm, a grep through /sys only shows that ISVTX is used for unlink()
checks on a directory.  Static vs. non-static probably only then
matters for build complexity vs. disk usage...

Simon.