linux/xattr.h and sys/xattr.h conflicts

[Rich Felker]

On Mon, Jan 06, 2014 at 12:31:35AM +1000, Allan McRae wrote:
> Hi,
> 
> The latest version of libcap (2.23) provides the header
> <sys/capability.h> which now includes <linux/xattr.h>.  From a quick
> look, it appears the libcap now library uses various things in the
> <linux/xattr.h> header that are not in the <sys/xattr.h> header.
> 
> 
> Anyway...  this has lead to bug reports in the form:
> 
> 1) compiles fine:
> #include <sys/xattr.h>
> #include <linux/xattr.h>
> 
> 2) generates compile errors:
> #include <linux/xattr.h>
> #include <sys/xattr.h>
> 
> 
> <linux/xattr.h> has:
> 
> #define XATTR_CREATE	0x1	/* set value, fail if attr already exists */
> #define XATTR_REPLACE	0x2	/* set value, fail if attr does not exist */
> 
> 
> <sys/xattr.h> has:
> 
> enum
> {
>   XATTR_CREATE = 1,	/* set value, fail if attr already exists.  */
> #define XATTR_CREATE	XATTR_CREATE
>   XATTR_REPLACE = 2	/* set value, fail if attr does not exist.  */
> #define XATTR_REPLACE	XATTR_REPLACE
> };
> 
> 
> so if the <linux/xattr.h> header is included first, then XATTR_CREATE is
> defined and that enum definition fails.
> 
> I some questions on my way to fix this.   Is there a point to that enum
> that I am missing or can it go?   If it needs to stay, can its member
> names be altered?

Inclusion of linux/*.h in userspace apps/libs is generally a bug in
the absence of a really good reason to be doing so. Here I think
libcap should just be fixed to use the libc header. If that's missing
some important definitions, they should be added.

Rich