This is the mail archive of the
mailing list for the glibc project.
Re: AC_HEADER_MAJOR vs. glibc 2.25(-to-be)
- From: Florian Weimer <fweimer at redhat dot com>
- To: Zack Weinberg <zackw at panix dot com>, autoconf at gnu dot org
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Thu, 1 Sep 2016 10:35:22 +0200
- Subject: Re: AC_HEADER_MAJOR vs. glibc 2.25(-to-be)
- Authentication-results: sourceware.org; auth=none
- References: <CAKCAbMgx-N-w4iuCh3+GkMOup=FQ749vd_qPJ2qyZusaVsnEgQ@mail.gmail.com>
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.)
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).
The larger question here is whether we can make toolchain changes which
alter the outcome of checks in existing (compiled) autoconf tests.
More and more, the invalid C used in autoconf tests blocks useful
enhancements to the toolchain.
Is it reasonable to expect that autoconf releases happen regularly
(twice a year), to match glibc/GCC/binutils changes, and that people run
autoconf before compiling software packages?