From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mo4-p00-ob.smtp.rzone.de (mo4-p00-ob.smtp.rzone.de [85.215.255.21]) by sourceware.org (Postfix) with ESMTPS id C78493858D1E for ; Sun, 26 Feb 2023 19:03:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C78493858D1E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=clisp.org Authentication-Results: sourceware.org; spf=none smtp.mailfrom=clisp.org ARC-Seal: i=1; a=rsa-sha256; t=1677438178; cv=none; d=strato.com; s=strato-dkim-0002; b=D5O5WuUB3iZjLf7VE3X+ha9lJobMxrH8tp25WRfL+pPKRtNQvvIA1H50Ex7plqwjwa ml7vK3JExsfy64VS6d47VEehdIFjJemzvfCDByo+8tYdeuY7r6EjCW4bJ+L4uxT4sfwj HrYu/3sG/QPp+7hyTBFaeQVEzn0DGRfANduhh5lrrikT7irbHACF48pFKrEkxJf9VJpU Fb1jRCWFskNo1vTFAwh6yjczzAc03MGBvyTjc03mmRaM6kkWxLSzQIbHnvh2t1Fwgum0 lAKOYcKVst3Bi1I12DkT7qi6+HQKzwKqg4amgRaNJCUWWn0tGbHwonyg8+EVmY2/rcxL eh2Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; t=1677438178; s=strato-dkim-0002; d=strato.com; h=References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From:Cc:Date: From:Subject:Sender; bh=JGPARXv3BWIs1+qpCcXBSh21SeokL2oOwdNVesV2ZYA=; b=GpWcg0/ayNtBbFEKcGbko8D39sM+6jGBIKWCQZr6iDV67psBNlUlEVcX5oSTrAJ3zD CDlWpaGlBRMTkEoqYLWqkbKe68MboWX+al392/yavB0DyHqVbQfwQBvMYX/Z/WdtpC9O DqUGE0Pv8IoVU2xRNWLTOHXXeHgWA569vkNZXUZXD3MiuaS5rpqojcNAshnUHobbUHVI 4ykMhZRsN3Pye3n7B3a6FSAuNI1LO/jmdwzkgnmKlaagEV9BVgOWvuOiINEbK1kS9U9n UVhIwMftEehCp85fiim6CvMnpMLvFi7ANgj5Cqpxltf8vShIWS+oLm3BtdbK4DDszl/t A/CQ== ARC-Authentication-Results: i=1; strato.com; arc=none; dkim=none X-RZG-CLASS-ID: mo00 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1677438178; s=strato-dkim-0002; d=clisp.org; h=References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From:Cc:Date: From:Subject:Sender; bh=JGPARXv3BWIs1+qpCcXBSh21SeokL2oOwdNVesV2ZYA=; b=sW60zdHTAUxUzxWXXXf/mATRaz7yOx/MoPWbmVCYPeci68fhPkOr122URjUsPSkaKz HWs8gAQ5uv9NKPZpjMxb9/5B5luRdIiLVoL1B9H8ie3y0xozhGJ7SZm/fRCE4s3yNFdQ RiFefSw2hlVylQ+zONHL+KQ8Biu6gRlOPqBq9fnJH/+owhOXewPSyufCsX3Th/lW6DPF AvpDFLVN+d9qL7wLxQOBk81pgHuUpjYul+7LxJsFUhdl9/LNZwjm+l1c+9uUaeR8l2Ke beR8+pacZTIPQQYxCM0YZlSckpmbdtStVigYHZ2qero+s2cQdyfLohtvgJieD1bIJgid zZ6w== X-RZG-AUTH: ":Ln4Re0+Ic/6oZXR1YgKryK8brlshOcZlIWs+iCP5vnk6shH0WWb0LN8XZoH94zq68+3cfpOe3KECwh34znSXNk38Jm0iqILh+Q==" Received: from nimes.localnet by smtp.strato.de (RZmta 49.3.0 AUTH) with ESMTPSA id f83259z1QJ2wizt (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits)) (Client did not present a certificate); Sun, 26 Feb 2023 20:02:58 +0100 (CET) From: Bruno Haible To: libc-alpha@sourceware.org, bug-gnulib@gnu.org Cc: Sachin Monga , Florian Weimer Subject: Re: Updating in glibc and gnulib Date: Sun, 26 Feb 2023 20:02:58 +0100 Message-ID: <3069302.YxpEyTPbXf@nimes> In-Reply-To: <87ilfvqq8u.fsf@oldenburg.str.redhat.com> References: <87ilfvqq8u.fsf@oldenburg.str.redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Spam-Status: No, score=-3.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,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: Florian Weimer wrote: > Does gnulib still override unconditionally? Gnulib does not override , and never did. That is, when a package that uses Gnulib does #include it will get the of the system (from glibc, *BSD, Cygwin, etc.). Only when a package uses the compiler option "-I /usr/include/sys" and #include there would be a conflict between what Gnulib ships and the installed file in /usr/include/sys. But nobody does that, because there would already be a conflict between and . What Gnulib does is to ship a copy of glibc's as , not . And it is used for a few compilation units only (essentially regex, fnmatch, glob, and a few others). > Why does gnulib bundle ? Gnulib takes the source code of regex, fnmatch, glob, and a few other functions from glibc and makes them portable to other platforms. Since this source code contains references to __glibc_unlikely, __attribute_warn_unused_result__, etc., Gnulib uses the copy of cdefs.h to define these macros in the way the source code shared with glibc expects it. Some of these symbols are also defined on other platforms, sometimes differently. Therefore Gnulib has to be careful to not override essential symbols of these other platforms. It's not trivial, but there appears to be enough room to navigate through the two constraints. [1] > In the past, some gnulib-using programs supplied their own copy > of instead, even when building against glibc. This caused > build failures in the glibc headers because they (quite reasonably) > assumed that defines the macros for that glibc version. You need to take this up with the respective packages. As I said above, Gnulib overrides , not . There were some problems around the 'glob' code, but they were resolved more than 1.5 years ago. This area is still a bit fragile, though. > We could move glibc's internal definitions to a new header, reducing > in scope, but presumably that means gnulib would just > starting bundling that other header, and we would have the same issue > once more. Yes, such a move would be pointless. Bruno [1] https://lists.gnu.org/archive/html/bug-gnulib/2023-01/msg00238.html