From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 343F13858296 for ; Mon, 27 Feb 2023 14:52:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 343F13858296 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1677509529; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ACDW9QRmtAlKOlcoF5wyLKyBT2MPuUnC9DH5y/dbtCM=; b=MVCdko1mIPYokld3t6ZGI4RGS+dZ5uiRQflG/O8tLG0FSyq1lLVDsYuSJoSXZtduVNoTwq 5I2VWCiqHP3GWL25fokHAvgY6LCP+MRr0hRTP1yWPJEh1gAh8EKCL4Pm+p8xYK3bNNJMSM ldkv/Sr/kUfoeZGiRqviVQkbaUwUElk= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-261-MrZKPdiyMbeWJp05euyN2Q-1; Mon, 27 Feb 2023 09:52:06 -0500 X-MC-Unique: MrZKPdiyMbeWJp05euyN2Q-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 441FC811E6E; Mon, 27 Feb 2023 14:52:06 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.45.226.66]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 43E551121314; Mon, 27 Feb 2023 14:52:05 +0000 (UTC) From: Florian Weimer To: Bruno Haible Cc: libc-alpha@sourceware.org, bug-gnulib@gnu.org, Sachin Monga , Siddhesh Poyarekar Subject: Re: Updating in glibc and gnulib References: <87ilfvqq8u.fsf@oldenburg.str.redhat.com> <3069302.YxpEyTPbXf@nimes> Date: Mon, 27 Feb 2023 15:52:03 +0100 In-Reply-To: <3069302.YxpEyTPbXf@nimes> (Bruno Haible's message of "Sun, 26 Feb 2023 20:02:58 +0100") Message-ID: <87k003ma98.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.3 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-4.5 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: * Bruno Haible: > Florian Weimer wrote: >> Does gnulib still override unconditionally? > > Gnulib does not override , and never did. Thanks for looking into this. gnulib's libc-config.h does this: | #ifndef __attribute_nonnull__ | /* either does not exist, or is too old for Gnulib. | Prepare to include , which is Gnulib's version of a | more-recent glibc . */ | =E2=80=A6 | /* Include our copy of glibc . */ | # include And as gnulib's uses the same _SYS_CDEFS_H header guard as glibc's, that effectively replaces with gnulib's . > That is, when a package that uses Gnulib does > #include > it will get the of the system (from glibc, *BSD, Cygwin, > etc.). Apparently not if it includes libc-config.h first. I think what happened is that the order of backporting commit 0b5ca7c3e551e5502f3be3b06453324fe8604e82 Author: Paul Eggert Date: Tue Sep 21 07:47:45 2021 -0700 regex: copy back from Gnulib (which brought in __attribute_nonnull__) and commit a643f60c53876be0d57b4b7373770e6cb356fd13 Author: Siddhesh Poyarekar Date: Wed Oct 20 18:12:41 2021 +0530 Make sure that the fortified function conditionals are constant was reversed on the glibc 2.34 branch, so the version check based on __attribute_nonnull__ would signal that system is too old. But with the second commit for fortified functions, glibc 2.34 headers started requiring other macros not present in gnulib's copy, so some projects using copied gnulib sources would start to fail. I backported the regex sync to glibc 2.34 in November, so this should now be solved because we now define __attribute_nonnull__ even on the 2.34 branch. I think only the 2.34 branch had this problem. I think we should have backported the __attribute_nonnull__-defining commit to glibc 2.34 earlier, when we noticed problems. Updating the gnulib-bundled copy only (which is what happened at first) wasn't the best resolution. Thanks, Florian