On 09/01/2016 08:08 PM, Zack Weinberg wrote: > On Wed, Aug 31, 2016 at 11:24 PM, Paul Eggert wrote: >> Zack Weinberg wrote: >>> Have I missed either a way to carry out the ideal solution, or a third >>> alternative? >> >> How about changing AC_HEADER_MAJOR to detect those warning messages? > > That's difficult, but more importantly it doesn't do any good till we > get an autoconf release out -- and then everyone using AC_HEADER_MAJOR > has to regenerate their configure script and release *their* software. > I'm hoping we can find a solution that can be implemented entirely > within glibc. I may be able to get some time at my $dayjob to get an autoconf release out the door before the glibc release; how much time do I have left, to know what priority I need to give this? And you are correct that a new autoconf won't help projects that don't re-run autoconf with the fix, but at a bare minimum, we can at least get gnulib to support the same macro definition as what autoconf 2.70 will have, so that projects using gnulib will at least not have to wait for an autoconf release, as well as having updated docs in the released autoconf manual that tell users what to do when they run into the problem. One other possibility that distros can do is to prime a config.site file, with $ac_cv_header_sys_types_h_makedev=no, to forcefully bypass the configure check that is normally done where would warn. It has to be in config.site, because non-glibc systems do not want to do that. Meanwhile, even without an autoconf release scheduled, I am currently working on patching the existing autoconf macro and documentation to match the current situation. It sounds to me like we want the following logic: If exists and defines major(), use that, else if exists, use that, else if defines major(), use that, else not available instead of the current broken logic: If defines makedev(), use that, else if exists, use that, else if exists, use that, else not available Does anyone see any flaws in my reasoning? I'll post a patch as a followup, if it passes testing on my end (I'm using Fedora rawhide as my testbed, which is definitely hitting the compilation failure with current glibc). -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org