[PATCH] features: version-gate _DYNAMIC_STACK_SIZE_SOURCE

[Andrew Kelley]

On 1/28/22 20:00, H.J. Lu wrote:
> On Fri, Jan 28, 2022 at 6:38 PM Andrew Kelley <andrew@ziglang.org> wrote:
>>
>> Without this patch, software compiled against glibc 2.34 headers but
>> then executed on a system with an older glibc version will attempt to
>> invoke `sysconf(_SC_SIGSTKSZ)` when MINSIGSTKSZ or SIGSTKSZ are used. On
>> glibcs older than 2.34, this will return -1 (with an errno of EINVAL),
>> effectively causing MINSIGSTKSZ and SIGSTKSZ to have the value of -1.
>>
>> This patch version-gates the _DYNAMIC_STACK_SIZE_SOURCE preprocessor
>> definition so that this problem cannot occur.
>>
>> Downstream patch:
>> https://github.com/ziglang/zig/commit/39083c31a550ed80f369f60d35791e98904b8096
>> ---
>>   include/features.h | 6 ++++--
>>   1 file changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/include/features.h b/include/features.h
>> index ab2b2caac4..77a8f8cc32 100644
>> --- a/include/features.h
>> +++ b/include/features.h
>> @@ -220,8 +220,10 @@
>>   # define _DEFAULT_SOURCE       1
>>   # undef  _ATFILE_SOURCE
>>   # define _ATFILE_SOURCE        1
>> -# undef  _DYNAMIC_STACK_SIZE_SOURCE
>> -# define _DYNAMIC_STACK_SIZE_SOURCE 1
>> +# if __GNUC_PREREQ (2,34)
>> +#  undef  _DYNAMIC_STACK_SIZE_SOURCE
>> +#  define _DYNAMIC_STACK_SIZE_SOURCE 1
> 
> You are changing a glibc 2.35 header file.   Isn't __GNUC_PREREQ (2,34)
> always true? Am I missing something?

You are correct.

Downstream we also have a patch that removes the __GLIBC_MINOR__ 
preprocessor definition. Instead, we pass it on the command line.

https://github.com/ziglang/zig/commit/4d48948b526337947ef59a83f7dbc81b70aa5723

The Zig project aims to support targeting many versions of glibc; not 
only the latest one. Our strategy is multi-faceted. For the shared 
objects, there is this project:
https://github.com/ziglang/glibc-abi-tool/

And then we have the headers. For the most part, the latest glibc 
headers are still correct for targeting systems with older glibc 
versions. Some of the other usages of __GNUC_PREREQ look to be 
supporting this use case to me. An occasional patch such as this one is 
needed to make it work correctly, however.

I can understand there would be hesitation to support such a use case. I 
hope that glibc maintainers would consider it however, because 
ultimately it is helping glibc users cross-compile, targeting their 
production systems from their development machines.

Thanks for your time.

> 
>> +# endif
>>   #endif
>>
>>   /* If nothing (other than _GNU_SOURCE and _DEFAULT_SOURCE) is defined,
>> --
>> 2.33.1
>>
> 
>