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
_______________________________________________
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
