libntpc.so

[Richard Laager]

On 12/14/20 3:21 PM, Hal Murray via devel wrote:
> I setup a new machine over the weekend.  Fedora 33, Python 3.9.0
> 
> After a build and install, ntpq couldn't find ntp.ntpc
> 
> I fixed things by setting up /etc/ld.so.conf.d/ntpd.conf
> containing /usr/local/lib64/ and running ldconfig.

Yeah, that's apparently what you have to do on Fedora (for any library 
built from source, not just NTPsec). See this old bug, for example, and 
various StackOverflow posts:
https://bugzilla.redhat.com/show_bug.cgi?id=144967

The pro of not including /usr/local is that you avoid random old 
user-built stuff breaking the system. The con is that you force users to 
jump through extra hoops if they want to build things from source.

> I have a Fedora 32 box, Python 3.8.6, that works without the extra directive
> to ldconfig.
> I can't figure out how.

Interesting. Check /etc/ld.so.conf, /etc/ld.so.conf.d/*.conf, 
LD_LIBRARY_PATH, all those folders for ntpc.so*, and the 
PYTHONDIR/PYTHONARCHDIR folders too.

> A Debian box has:
>    /etc/ld.so.conf.d/fakeroot-x86_64-linux-gnu.conf
>    /etc/ld.so.conf.d/libaes_siv.conf
>    /etc/ld.so.conf.d/libc.conf
>    /etc/ld.so.conf.d/x86_64-linux-gnu.conf
> with a couple of /usr/local/lib in there but no /usr/local/lib64

Debian doesn't use the "lib64" style naming. It has the traditional 
"lib" and then uses what it calls "multiarch", so you have things like 
/usr/lib/x86_64-linux-gnu (and /usr/local versions too).

I'm getting /usr/local/lib by default from waf, which is listed in 
/etc/ld.so.conf.d/libc.conf. So that's how that works.

> ntpq says:
>      import ntp.ntpc
> 
> Should that ntp be there?   We aren't installing in xxx/ntp/ any more.

It is correct as is. Those details are unrelated to each other.

-- 
Richard