On Thu, Aug 11, 2016 at 02:42:50PM +0200, Thomas Deutschmann wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > Hi, > > collectd [1] now longer builds against xfsprogs-4.7.0 due to a > conflict with MS_RDONLY definition in sys/mount.h by glibc vs exposed > kernels header by xfsprogs due to the include of linux/fs.h. > > Upstream bug: https://github.com/collectd/collectd/issues/1877 > > Gentoo-Bug: https://bugs.gentoo.org/590998 > > > I am bringing this to your attention to ask if you want to do anything > to fix this in xfsprogs or do you consider that as a bug in collectd. XFS grabs structure definitions that are exposed by the kernel from linux/fs.h because they are used in the XFS ioctl API definitions, as well as other syscalls that aren't supported by glibc. So we kind of need it to make sure we pick up the system definition of what is supported and what isn't. That userspace unconditionally redefines the kernel mount API flags with the same names and values seems like a bug in whatever provides those definitions. My current userspace doesn't even have a sys/mount.h file - I can only find a platform specific header: /usr/include/x86_64-linux-gnu/sys/mount.h Which contains a stale, partial copy of /usr/include/linux/fs.h. That platform header should pull the definitions from linux/fs.h if it exists, and only if it doesn't should it define it's own. Esepcially as the only userspace component is 3 function prototypes at the bottom of the file. However, I'm probably not the best person to ask how this should all be structured properly - it seems pretty obvious to me that libraries should include system definitions of interfaces, and system libraries should include the kernel definitions of kernel interfaces. So for collectd I'm not sure what the solution is right now - this is only going to get more problematic as we push lots of new kernel API support into xfsprogs over the next few months that glibc will not support directly for some time, if ever. People using XFS interfaces usually want to compile programs that will work on kernels that support those functions (i.e. they use runtime support checks, not compile time), so from the xfsprogs perspective we are kind of stuck between a rock and a hard place here.... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
