Subject: Re: ntp4: ELF and missing objects in the shared library.
To: Jonathan Stone <jonathan@DSG.Stanford.EDU>
From: Simon Burge <email@example.com>
Date: 01/20/2000 14:35:46
Jonathan Stone wrote:
> In message <200001200145.MAA18689@balrog.supp.cpr.itg.telecom.com.au>,
> Simon Burge writes:
> >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
> 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
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...