[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] AC_HEADER_MAJOR: port to glibc 2.25

From: Zack Weinberg
Subject: Re: [PATCH] AC_HEADER_MAJOR: port to glibc 2.25
Date: Wed, 14 Sep 2016 11:27:58 -0400

On Wed, Sep 14, 2016 at 9:26 AM, Eric Blake <address@hidden> wrote:
> glibc 2.25 is deprecating the namespace pollution of sys/types.h
> injecting major(), minor(), and makedev() into the compilation
> environment, with a warning that insists that users include
> <sys/sysmacros.h> instead.  However, because the expansion of
> AC_HEADER_MAJOR didn't bother checking sys/sysmacros.h until
> after probing whether sys/types.h pollutes the namespace, it was
> not defining MAJOR_IN_SYSMACROS, with the result that code
> compiled with -Werror chokes on the deprecation warnings because
> it was not including sysmacros.h.
> In addition to fixing autoconf (which only benefits projects
> that rebuild configure after this fix is released), we can also
> give a hint to distros on how they can populate with
> a cache variable to force pre-existing configure scripts without
> the updated macro to behave sanely in the presence of glibc 2.25.

Thanks for writing this patch.

> For this patch, I kept the status quo of assuming that if
> sys/sysmacros.h exists, then it probably defines major/minor/makedev;
> if you want me to rework the patch to explicitly check that this
> is the case, I can do that as well (probably best as a followup
> patch, in case downstreams want to backport one idea without the
> other).

glibc's sys/sysmacros.h _only_ defines major/minor/makedev.  What I'd
worry about is whether any other C library has a different header with
the same name; "sysmacros" is pretty generic.  I don't have any
evidence either way on that question.

> @@ -5977,6 +5977,27 @@ Particular Headers
>  @code{makedev}, but @file{sys/mkdev.h} does, define
>  @code{MAJOR_IN_MKDEV}; otherwise, if @file{sys/sysmacros.h} does, define

This part of the description should probably be adjusted to match what
the code does now.

> +To properly use any of these three functions, your code should contain
> +something like:

Also, I think "three functions" here is meant to refer to
major/minor/makedev, but it tripped me up the first time I read it.  I
suggest instead

   Detect the headers required to use @code{makedev}, @code{major}, and
   @code{minor}.  These functions may be defined by @file{sys/mkdev.h},
   @code{sys/sysmacros.h}, or @file{sys/types.h}.

   @code{AC_HEADER_MAJOR} defines @code{MAJOR_IN_MKDEV} if they are in
   @file{sys/mkdev.h}, or @code{MAJOR_IN_SYSMACROS} if they are in
   @file{sys/sysmacros.h.}.  If neither macro is defined, they are either
   in @file{sys/types.h} or they are unavailable.

   To portably use these functions, your code should contain something

and then your @verbatim block.

(Should AC_HEADER_MAJOR maybe throw an error if none of the possible
headers we know about defines major/minor/makedev?  I believe this is
the case on MinGW, for instance.)

> +Note that glibc 2.25 issues a deprecation warning if these functions are
> +used from @file{sys/types.h} without also using @file{sys/sysmacros.h},
> +but that configure scripts built with versions of autoconf prior to 2.70
> +did not correctly define @code{MAJOR_IN_SYSMACROS} in that scenario; on
> +systems where that is a problem, you can use the workaround of priming
> +the configure cache by setting @code{ac_cv_header_sys_types_h_makedev}
> +to 'no', perhaps as part of a @file{} site default file
> +(@pxref{Site Defaults}).

This is a really long sentence.  Also, "used from @file{sys/types.h}
without also using @file{sys/types.h}" is confusing, and since this is
the Autoconf manual, probably the paragraph should highlight the
affected Autoconf versions first.  Suggested:

   Note: Configure scripts built with Autoconf 2.69 or earlier will
   not detect a problem if @file{sys/types.h} contains definitions of
   @code{major}, @code{minor}, and/or @code{makedev} that trigger
   compiler warnings upon use.  This is known to occur with GNU libc
   2.25, where those definitions are being deprecated, to reduce
   namespace pollution.  If it is not practical to regenerate affected
   software's configure scripts with Autoconf 2.70, you can work around
   the problem by setting @samp{ac_cv_header_sys_types_h_makedev=no} in
   a @file{} site default file (@pxref{Site Defaults}).

> +# Thanks to glibc 2.25, we need the following logic:
> +# If <sys/sysmacros.h> compiles, assume it provides the macros.
> +# Otherwise, if <sys/types.h> provides them, nothing further to do.
> +# Otherwise, if <sys/mkdev.h> exists, assume it provides the macros.

I think we should check sys/types.h last.  That will future-proof
against C libraries where these functions are in both sys/mkdev.h and
sys/types.h deciding to do the same deprecation that glibc has done.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]