Same with SIGSTKSZ.

This starts with a more philosophical problem: glibc 2.34 defines these macros as expanding to an expression that resolves as a dynamic, non-constant value. This addresses the fact that, from glibc's perspective, and indeed for any libc that wants to support a vast array of architectures, they are non-constant values. See:

https://sourceware.org/glibc/wiki/Release/2.34#Non-constant_MINSIGSTKSZ_and_SIGSTKSZ

The reason is that MINSIGSTKSZ can either be so huge that it effectively rules out some hardware that currently can run glibc-based programs, or it can be non-constant. As glibc chose the latter route, it might be useful to contrast with a libc that chose the former route, Darwin:

#define MINSIGSTKSZ     32768   /* (32K)minimum allowable stack */
#define SIGSTKSZ        131072  /* (128K)recommended stack size */

However, the previous constant can be useful in actual programs if taken as somewhere close to a "floor", e.g. see:

• Dynamically size sigaltstk in rustc rust#113528
• Dynamically size sigaltstk in std rust#113525

The more practical issue that spawns out of this: if this value is incorrect, it can easily lead to data corruption. Huge amounts of hardware state may potentially need to be managed by a signal handler, and clobbering user data is unacceptable.