[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Eric Blake
Subject: Re: AC_HEADER_MAJOR vs. glibc 2.25(-to-be)
Date: Tue, 13 Sep 2016 16:36:46 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0

On 09/01/2016 08:08 PM, Zack Weinberg wrote:
> On Wed, Aug 31, 2016 at 11:24 PM, Paul Eggert <address@hidden> 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
file, with $ac_cv_header_sys_types_h_makedev=no, to forcefully bypass
the configure check that is normally done where <sys/types.h> would
warn.  It has to be in, 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

If <sys/sysmacros.h> exists and defines major(), use that,
else if <sys/mkdev.h> exists, use that,
else if <sys/types.h> defines major(), use that,
else not available

instead of the current broken logic:

If <sys/types.h> defines makedev(), use that,
else if <sys/mkdev.h> exists, use that,
else if <sys/sysmacros.h> 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

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]