libraries, pthread cleanup, remove libthr support

[Eric S. Raymond]

Hal Murray via devel <devel at ntpsec.org>:
> 
> I'd like to get rid of wafhelpers/check_pthread.py
> 
> There may have been some PTHREAD conditionals in our code ages ago, but they 
> are all gone.
> 
> The main thing check_pthread is doing is setting up to use libthr rather than 
> libpthread.
> 
> FreeBSD uses libthr.so rather than libpthread.so.  But it has links, so asking 
> for -libpthread works but ldd will show libthr.so
> 
> lrwxr-xr-x  1 root  wheel  10 Dec  6 20:12 /usr/lib/libpthread_p.a -> 
> libthr_p.a
> lrwxr-xr-x  1 root  wheel   9 Dec  6 20:12 /usr/lib/libpthread.so -> libthr.so
> lrwxr-xr-x  1 root  wheel   8 Dec  6 20:12 /usr/lib/libpthread.a -> libthr.a
> 
> So FreeBSD works without anything special.
> 
> 
> The other interesting case that I can test locally is musl on Alpine Linux.  It doesn't have libpthred.so, but does have 
> -rw-r--r--    1 root     root             8 Jun 19  2018 /usr/lib/libpthread.a
> alp:~$ cat /usr/lib/libpthread.a
> !<arch>
> alp:~$ 
> 
> I assume that is a flag for some magic, but I haven't tracked it down.  Linking with -lpthread seems to get folded into musl:
> alp:~$ ldd /usr/local/sbin/ntpd
>         /lib/ld-musl-x86_64.so.1 (0x7957db6bc000)
>         libcrypto.so.1.0.0 => /lib/libcrypto.so.1.0.0 (0x7957db051000)
>         libcap.so.2 => /usr/lib/libcap.so.2 (0x7957dae4c000)
>         libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x7957dac3a000)
>         libc.musl-x86_64.so.1 => /lib/ld-musl-x86_64.so.1 (0x7957db6bc000)
>         libz.so.1 => /lib/libz.so.1 (0x7957daa23000)
> alp:~$ 
> 
> In hindsight, it seems reasonable to expect -lpthread and friends (eg -lm and -lrt) to work, one way or the other.  Not having that would be a huge pain in the ass when porting code.
> 
> Their man pages are normal Linux pages.
> 
> Any reason not to push this?

Nope.  Looks good to me.

> Why is -lrt optional?
>     ctx.check_cc(lib="rt", mandatory=False, comment="realtime library")

The -lrt option expllicitly links support for the POSIX real-time extension.
Some of our build targets require it to link clock_gettime/clock_settime,
some don't (because libc includes the real-time extension).

In general, if the -lrt option exists at all, it is required.

> We need it for timers: timer_create, timer_settime, and timer_gettime.

As expected.

> Do POSIX specs include the library?

Yes, but it is formally an extension and toolchain providers sometimes did
not support it in the past.  Nowadays you can always get it with -lrt.  In the
future I expect fewer and fewer build targets will require this.

> Even if the actual code is in libc, I'd expect most system would have a dummy librt just to help portability.

You might think, but not the last time I checked.  This is a minor source of
porting annoyance oin several of my projects, not just NTPsec.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.