All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Laight <David.Laight@ACULAB.COM>
To: 'Arnout Vandecappelle' <arnout@mind.be>,
	"buildroot@buildroot.org" <buildroot@buildroot.org>
Subject: Re: [Buildroot] [git commit] package/ntp: Fix building with glibc 2.34+
Date: Thu, 23 Sep 2021 08:23:19 +0000	[thread overview]
Message-ID: <4348b4b5c0844714baffcfee40bfec1a@AcuMS.aculab.com> (raw)
In-Reply-To: <20210922210348.96B9A8CA2B@busybox.osuosl.org>

From: Arnout Vandecappelle
> Sent: 22 September 2021 21:13
...
> On attempt to build ntp with glibc 2.34 the following error happens:
> -------------------------------->8------------------------------
> In file included from .../output/host/lib/gcc/i586-buildroot-linux-gnu/10.3.0/include-
> fixed/pthread.h:42,
>                  from work_thread.c:13:
> work_thread.c:45:57: error: missing binary operator before token "("
>    45 | #if defined(PTHREAD_STACK_MIN) && THREAD_MINSTACKSIZE < PTHREAD_STACK_MIN
>       |                                                         ^~~~~~~~~~~~~~~~~
> -------------------------------->8------------------------------
> 
> That's because starting from glibc 2.34 PTHREAD_STACK_MIN gets determined
> dynamically in runtime via sysconf(), see [1].
...
> +In glibc 2.34+ PTHREAD_STACK_MIN is not a compile-time constant which
> +could mean different stack sizes at runtime on different architectures
> +and it also causes compile failure. Default glibc thread stack size
> +or 64Kb set by ntp should be good in glibc these days.
...
> + #ifndef THREAD_MINSTACKSIZE
> + # define THREAD_MINSTACKSIZE	(64U * 1024)
> + #endif
> +-#ifndef __sun
> ++#if !defined(__sun) && !defined(__GLIBC__)
> + #if defined(PTHREAD_STACK_MIN) && THREAD_MINSTACKSIZE < PTHREAD_STACK_MIN
> + # undef THREAD_MINSTACKSIZE
> + # define THREAD_MINSTACKSIZE PTHREAD_STACK_MIN

I'm not convinced that is the correct fix.
The same issues apply to the thread stack as they do to the signal stack.
Albeit the sizes are larger.

The very reason that PTHREAD_STACK_MIN isn't a compile-time constant
is that the value cannot be determined at compile time.
While 64k may seem ok for now, there is no reason for it to be enough.

Possibly something like:
#ifndef PTHREAD_STACK_MIN
#define THREAD_MINSTACKSIZE	(64U * 1024)
#else
#define THREAD_MINSTACKSIZE	(PTHREAD_STACK_MIN > 64U * 1024 ? PTHREAD_STACK_MIN : 64U * 1024)
#endif
would be better.
Although a form that only evaluates PTHREAD_STACK_MIN once may be better.

Quite why ntp is setting the thread stack size is any bodies guess though.
It can only get it wrong in a different way!
Although ISTR one version of ntp thinking itself so important
that it locked all its memory.
So maybe it is just trying to reduce that locked memory footprint.

Given that it's pretty much impossible for ntp to accurately set
the time to less than the RTT to the server (it can't tell whether
the RTT delays are on the tx or rx side) I can't see that it matters.

Anyone who needs sub-ms time sync has bigger problems.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)

_______________________________________________
buildroot mailing list
buildroot@lists.buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

  reply	other threads:[~2021-09-23  8:25 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-22 20:13 [Buildroot] [git commit] package/ntp: Fix building with glibc 2.34+ Arnout Vandecappelle
2021-09-23  8:23 ` David Laight [this message]
2021-09-23  9:26   ` Arnout Vandecappelle
2021-09-23 21:34     ` Peter Seiderer
2021-10-05  6:27       ` Peter Korsgaard

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4348b4b5c0844714baffcfee40bfec1a@AcuMS.aculab.com \
    --to=david.laight@aculab.com \
    --cc=arnout@mind.be \
    --cc=buildroot@buildroot.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.