Re: Updating <sys/cdefs.h> in glibc and gnulib

[Florian Weimer <fweimer@redhat.com>]

* 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