From: Andrew Kelley <andrew@ziglang.org>
To: "H.J. Lu" <hjl.tools@gmail.com>
Cc: GNU C Library <libc-alpha@sourceware.org>
Subject: Re: [PATCH] features: version-gate _DYNAMIC_STACK_SIZE_SOURCE
Date: Fri, 28 Jan 2022 21:04:01 -0700 [thread overview]
Message-ID: <f9344eeb-4072-8e2d-dd0f-0b8411e0ec8f@ziglang.org> (raw)
In-Reply-To: <CAMe9rOq67vPJZ8hVwYDjHarXAZ4dk4uN-=15Tib2541+4_hswg@mail.gmail.com>
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
>>
>
>
next prev parent reply other threads:[~2022-01-29 4:04 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-29 2:37 Andrew Kelley
2022-01-29 3:00 ` H.J. Lu
2022-01-29 4:04 ` Andrew Kelley [this message]
2022-01-29 4:15 ` Andrew Kelley
2022-01-29 10:41 ` Szabolcs Nagy
2022-02-01 16:37 ` Florian Weimer
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=f9344eeb-4072-8e2d-dd0f-0b8411e0ec8f@ziglang.org \
--to=andrew@ziglang.org \
--cc=hjl.tools@gmail.com \
--cc=libc-alpha@sourceware.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).