Re: AC_HEADER_MAJOR vs. glibc 2.25(-to-be)

[Zack Weinberg <zackw at panix dot com>]

On Thu, Sep 1, 2016 at 12:37 AM, Nick Bowler <nbowler@draconx.ca> wrote:
> On 8/31/16, Zack Weinberg <zackw@panix.com> wrote:
>> glibc 2.25 is going to deprecate the definition of 'major', 'minor',
>> and 'makedev' by  sys/types.h; see
>> https://sourceware.org/bugzilla/show_bug.cgi?id=19239 for rationale.
>> (It was found to be impractical to remove sys/types.h from stdlib.h.)
>> Unfortunately, AC_HEADER_MAJOR does not detect that these macros are
>> now throwing warning messages if you don't include sys/sysmacros.h,
>> and this is reported to break software that uses -Werror (see the very
>> end of the above bug report).
>
> It seems that the simplest short term solution is to just not use
> -Werror when building packages.  Other than the warning, the header
> detection worked, and the test is behaving as documented, right?

AC_HEADER_MAJOR is obeying the letter of its documentation but not the
spirit.  People using it reasonably expect that it should handle this
transition seamlessly for them.  They've already gone to the trouble
of writing

    #include <sys/types.h>
    #ifdef MAJOR_IN_MKDEV
    #include <sys/mkdev.h>
    #elif MAJOR_IN_SYSMACROS
    #include <sys/sysmacros.h>
    #endif

and shouldn't that be enough, not only to keep their program working
when glibc actually pulls the plug on the definitions in
<sys/types.h>, but to avoid the deprecation warnings?

>> The ideal solution to this problem would be if there _already existed_
>> a way for sys/types.h to detect that it's being included by an
>> autoconf test program.
>
> This is not really ideal as it goes directly against the Autoconf
> philosophy that the test cases are representative of the actual
> compilation environment.

Normally I'm on board with that, but it leaves me pretty well up a creek here...

> I have a question though, if these macros are deprecated, will they
> be removed from <sys/types.h> eventually?  If they're going to be
> removed, why not just punt them right now?  If they're not going to
> be removed, why bother with the warnings?

We (glibc) don't generally like to delete things from the headers with
no advance notice.  The plan is to have deprecation warnings for at
least one release, and then flip the switch.  Exactly which future
release flips the switch will depend on how many complaints we get
about the change.

zw