[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Updating <sys/cdefs.h> in glibc and gnulib
From: |
Florian Weimer |
Subject: |
Re: Updating <sys/cdefs.h> in glibc and gnulib |
Date: |
Mon, 27 Feb 2023 15:52:03 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) |
* Bruno Haible:
> Florian Weimer wrote:
>> Does gnulib still override <sys/cdefs.h> unconditionally?
>
> Gnulib does not override <sys/cdefs.h>, and never did.
Thanks for looking into this. gnulib's libc-config.h does this:
| #ifndef __attribute_nonnull__
| /* <sys/cdefs.h> either does not exist, or is too old for Gnulib.
| Prepare to include <cdefs.h>, which is Gnulib's version of a
| more-recent glibc <sys/cdefs.h>. */
| …
| /* Include our copy of glibc <sys/cdefs.h>. */
| # include <cdefs.h>
And as gnulib's <cdefs.h> uses the same _SYS_CDEFS_H header guard as
glibc's, that effectively replaces <sys/cdefs.h> with gnulib's
<cdefs.h>.
> That is, when a package that uses Gnulib does
> #include <sys/cdefs.h>
> it will get the <sys/cdefs.h> 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 <eggert@cs.ucla.edu>
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 <siddhesh@sourceware.org>
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 <sys/cdefs.h> is too old.
But with the second commit for fortified functions, glibc 2.34 headers
started requiring other macros not present in gnulib's <cdefs.h> 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