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

2016-09-13 Thread Eric Blake
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? > > Th

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

2016-09-13 Thread Eric Blake
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 >

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

2016-09-13 Thread Eric Blake
[adding libvirt list, as this is what sparked my investigations so far today] On 09/13/2016 04:36 PM, Eric Blake wrote: > 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 norma

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

2016-09-13 Thread Eric Blake
On 09/13/2016 05:31 PM, Eric Blake wrote: [hit send too soon] > Okay, I have confirmed that this prime-the-cache idea DOES work, using > libvirt.git commit 419bc8cf (one commit prior to d53fa838 which > installed a hack into libvirt to force the use of -Werror for the > duration of AC_HEADER_MAJO

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

2016-09-13 Thread Zack Weinberg
On Tue, Sep 13, 2016 at 5:36 PM, Eric Blake wrote: > 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? Per https://sourceware.org/glibc/wiki/Release/2.25, the