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

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

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

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-01 Thread Zack Weinberg
On Thu, Sep 1, 2016 at 9:32 PM, Paul Eggert wrote: >>> 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? >> >>

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

2016-09-01 Thread Paul Eggert
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

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

2016-09-01 Thread Zack Weinberg
On Thu, Sep 1, 2016 at 12:37 AM, Nick Bowler wrote: > On 8/31/16, Zack Weinberg 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

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

2016-09-01 Thread Zack Weinberg
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

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

2016-09-01 Thread Florian Weimer
On 09/01/2016 04:27 AM, Zack Weinberg 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.)

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

2016-08-31 Thread Florian Weimer
On 09/01/2016 06:37 AM, Nick Bowler wrote: 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? -Werror does not work because warnings from

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

2016-08-31 Thread Nick Bowler
On 8/31/16, Zack Weinberg 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

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

2016-08-31 Thread Paul Eggert
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? ___ Autoconf mailing list Autoconf@gnu.org