From: Bruno Haible <bruno@clisp.org>
To: libc-alpha@sourceware.org, bug-gnulib@gnu.org
Cc: Sachin Monga <smonga@linux.ibm.com>, Florian Weimer <fweimer@redhat.com>
Subject: Re: Updating <sys/cdefs.h> in glibc and gnulib
Date: Sun, 26 Feb 2023 20:02:58 +0100 [thread overview]
Message-ID: <3069302.YxpEyTPbXf@nimes> (raw)
In-Reply-To: <87ilfvqq8u.fsf@oldenburg.str.redhat.com>
Florian Weimer wrote:
> Does gnulib still override <sys/cdefs.h> unconditionally?
Gnulib does not override <sys/cdefs.h>, and never did.
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.).
Only when a package uses the compiler option "-I /usr/include/sys"
and
#include <cdefs.h>
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 <time.h> and <sys/time.h>.
What Gnulib does is to ship a copy of glibc's <sys/cdefs.h> as <cdefs.h>,
not <sys/cdefs.h>. And it is used for a few compilation units only
(essentially regex, fnmatch, glob, and a few others).
> Why does gnulib bundle <sys/cdefs.h>?
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 <sys/cdefs.h> instead, even when building against glibc. This caused
> build failures in the glibc headers because they (quite reasonably)
> assumed that <sys/cdefs.h> defines the macros for that glibc version.
You need to take this up with the respective packages. As I said above,
Gnulib overrides <cdefs.h>, not <sys/cdefs.h>.
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
> <sys/cdefs.h> 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
next prev parent reply other threads:[~2023-02-26 19:03 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-21 10:14 Florian Weimer
2023-02-26 19:02 ` Bruno Haible [this message]
2023-02-27 14:52 ` Florian Weimer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3069302.YxpEyTPbXf@nimes \
--to=bruno@clisp.org \
--cc=bug-gnulib@gnu.org \
--cc=fweimer@redhat.com \
--cc=libc-alpha@sourceware.org \
--cc=smonga@linux.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).