Re: [PATCH] Include sysmacros.h where needed

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

 



On Thu, Apr 14, 2016 at 10:08:33PM +0200, Martin Kletzander wrote:
On Thu, Apr 14, 2016 at 03:30:44PM +0100, Daniel P. Berrange wrote:
On Thu, Apr 14, 2016 at 04:14:23PM +0200, Martin Kletzander wrote:
So in glibc-2.23 sys/sysmacros.h is no longer included from sys/types.h
and we don't build because of the usage of major/minor/makedev macros.
Simply add sys/sysmacros.h into files that are using any of these
macros.

Signed-off-by: Martin Kletzander <mkletzan@xxxxxxxxxx>
---
I noticed this after update to glibc-2.23 and don't worry, there are
more project that fail compiling due to the same issue.

I can't find it in their repository, but I think it's safe to assume
that stuff will break sooner or later if we don't fix it.  The closest
thing I've found is this thread:

  https://marc.info/?l=glibc-alpha&m=144790641508520

>From that mailing list thread (actually just one mesage I've found out,
I haven't read the whole thread) there should've been some deprecation
warning for few releases, but apparently there isn't.

Technically it's a build-breaker fix, but I'm sending it for review in
case there is a system that does not have sys/sysmacros.h installed
for some reason.  Then we'd have to resort to using AC_HEADER_MAJOR.

sys/sysmacros.h appears to be a glibc invention, so any other
platforms would break frm this - eg mingw, *bsd, os-x.


So it could possibly also break with µClibc and os on.  So it's
probably the case for using AC_HEADER_MAJOR then.

I think requiring sys/sysmacros.h is pretty dubious since the
man page for major, minor & makedev is saying you should be
using sys/types.h to get them.


Well, it's probably just not updated.  makedev.3 man page comes from
kernel man pages project and not glibc.

Finally, I think this is the kind of thing that is gnulib's
role to address.


I'm rather thinking that's what AC_HEADER_MAJOR is for and sensible
reasons go together even only from this discussion.  How would gnulib be
able to handle that?  By having its own sys/types.h file?  I'm not that
familiar with how that works.


I sent a v2 so you and others can see how that looks like:

https://www.redhat.com/archives/libvir-list/2016-April/msg00947.html

Martin

Attachment: signature.asc
Description: Digital signature

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list

[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]