From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.ziglang.org (mail.ziglang.org [108.61.23.47]) by sourceware.org (Postfix) with ESMTPS id 6B01F3858D28 for ; Sat, 29 Jan 2022 04:15:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 6B01F3858D28 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=ziglang.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=ziglang.org Message-ID: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ziglang.org; s=mail; t=1643429738; bh=RuaKRHsDAMNNazVH8PxDVrb5naME8OVVLnfhhurDHLc=; h=Date:Subject:From:To:Cc:References:In-Reply-To; b=YZJCpPEG0zas2WYikHZdpIfIwbxhCv6rzq7g6NQJxQvUVAH2dJHZ54+uJBCbbTRl3 Egsp8E3VuWwR5qUVHpcbJ8bbCHAAitbAQkQZWYCaHFHynHPEwJg4qKIhCu0GoYX77Y //DOBlIVPrPcYBNHGDxWZov7h6hwu7ppCJWgn7OY= Date: Fri, 28 Jan 2022 21:15:36 -0700 MIME-Version: 1.0 Subject: Re: [PATCH] features: version-gate _DYNAMIC_STACK_SIZE_SOURCE Content-Language: en-US From: Andrew Kelley To: "H.J. Lu" Cc: GNU C Library References: <20220129023727.1496360-1-andrew@ziglang.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-11.1 required=5.0 tests=BAYES_00, BODY_8BITS, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jan 2022 04:15:39 -0000 On 1/28/22 21:04, Andrew Kelley wrote: > On 1/28/22 20:00, H.J. Lu wrote: >> On Fri, Jan 28, 2022 at 6:38 PM Andrew Kelley 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. I just noticed that, while the downstream patch that I linked has the correct improvement, I bungled the upstream patch here because I misunderstood what __GNUC_PREREQ does. This is the actual patch that I am proposing: --- 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 (__GLIBC__ == 2 && __GLIBC_MINOR__ >= 34) || __GLIBC__ > 2 +# undef _DYNAMIC_STACK_SIZE_SOURCE +# define _DYNAMIC_STACK_SIZE_SOURCE 1 +# endif #endif /* If nothing (other than _GNU_SOURCE and _DEFAULT_SOURCE) is defined,