On 09/01/2016 08:16 PM, Zack Weinberg wrote:
> 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 autoconf manual currently doesn't say how to USE the results of
AC_HEADER_MAJOR - it only states that MAJOR_IN_MKDEV or
MAJOR_IN_SYSMACROS might be defined.  But your formulation of the
correct usage _looks_ correct to me, and probably SHOULD be in the
manual.  At which point, the remaining trick to solve is that autoconf
SHOULD be setting MAJOR_IN_SYSMACROS for glibc, but isn't, because it
short-circuits at the point where it sees the pollution in
<sys/types.h>.  I think that rewriting the macro to check for
<sys/sysmacros.h> _first_, not last, will get MAJOR_IN_SYSMACROS set;
and then if programs ARE using the formulation you spell out above, then
we have the desired situation that configure works and the code compiles
without warnings.

Of course, if there were a way for glibc to detect that it was being run
under autoconf, and in that situation intentionally refuse to declare
major/minor/makedev, then existing autoconf clients will already fall
back to defining MAJOR_IN_SYSMACROS.  I just don't know if I feel
comfortable with glibc mucking with the build to compile one way under
autoconf and another way in real life, as autoconf's goal is to see what
will happen in real life.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org