collectd don't work with xfsprogs-4.7.0

[Whissi]

When building collectd against xfsprogs-4.7.0 compilation will fail

libtool: compile:  x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I./daemon -DPREFIX=\"/usr\" -DCONFIGFILE=\"/etc/collectd.conf\" -DLOCALSTATEDIR=\"/var\" -DPKGLOCALSTATEDIR=\"/var/lib/collectd\" -DPIDFILE=\"/var/run/collectd.pid\" -DPLUGINDIR=\"/usr/lib64/collectd\" -DPKGDATADIR=\"/usr/share/collectd\" -Wall -O2 -pipe -march=ivybridge -mtune=ivybridge -mno-xsaveopt -frecord-gcc-switches -c utils_mount.c  -fPIC -DPIC -o .libs/utils_mount.o
In file included from /usr/include/xfs/linux.h:35:0,
                 from /usr/include/xfs/xfs.h:37,
                 from /usr/include/xfs/xqm.h:21,
                 from utils_mount.c:30:
/usr/include/sys/mount.h:35:3: error: expected identifier before numeric constant
   MS_RDONLY = 1,  /* Mount read-only.  */
   ^
make[3]: *** [Makefile:3916: utils_mount.lo] Error 1

This is https://bugs.gentoo.org/show_bug.cgi?id=590998

[rubenk]

Hi @Whissi!

That error message makes no sense to me. MS_RDONLY is an enum. The xfs headers must redefine it. In any case, this seems to be a bug in xfsprogs.

[Whissi]

Yes, it is re-defininig MS_RDONLY in some way: From xfs/linux.h:

#include <linux/fs.h> /* fsxattr defintion for new kernels */

and linux/fs.h (from linux-4.4):

[...]
/*
 * These are the fs-independent mount-flags: up to 32 flags are supported
 */
#define MS_RDONLY        1      /* Mount read-only */
#define MS_NOSUID        2      /* Ignore suid and sgid bits */
[...]

but /usr/include/sys/mount.h from glibc-2.23:

/* These are the fs-independent mount-flags: up to 16 flags are
   supported  */
enum
{
  MS_RDONLY = 1,                /* Mount read-only.  */
#define MS_RDONLY       MS_RDONLY
  MS_NOSUID = 2,                /* Ignore suid and sgid bits.  */
[...]

I am not sure if this is a bug within xfsprogs. You can also argue collectd shouldn't include mount.h anymore when using >=xfsprogs-4.7.0, can't you (at least a simple test removing the include seems to work)?

[rubenk]

Thanks. So the glibc headers and kernel headers are out of sync, and xfsprogs exposes the kernel definitions. I really don't like patching around it, glibc headers should be safe to include.

[rubenk]

Reported upstream by @Whissi: http://oss.sgi.com/pipermail/xfs/2016-August/050835.html

[octo]

Is there anything left to be done on our end?

[rubenk]

No, I'm afraid not.

[Whissi]

Wait, I don't see that you have https://gitweb.gentoo.org/repo/gentoo.git/tree/app-admin/collectd/files/collectd-5.5.2-issue-1877.patch merged. So collected.git should still be affected.

[rubenk]

@Whissi affected yes, this needs to be fixed either in glibc or in xfsprogs.

Did you send a PR for that patch? I forgot.

[Whissi]

I did not send a PR. The patch is based on your GIST.

xfsprogs upstream isn't sure if xfsprogs is the place to fix the issue, see http://oss.sgi.com/pipermail/xfs/2016-August/050848.html

I haven't contacted glibc project.

Because the patch only re-orders code in collectd to workaround the issue I would say "fix it in collectd".

[rubenk]

I don't mind working around it, but it would nice to have a constructive fix for this in glibc.

Can you turn your patch into a PR?