On 3/1/18 1:13 PM, Darrick J. Wong wrote:
> From: Darrick J. Wong <darrick.wong@xxxxxxxxxx>
>
> Fix the ordering of the header includes in all the scrub source. We put
> xfs.h first so that it will pull in include/linux.h which pulls in
> linux/fs.h + whatever overrides are necessary (currently limited to
> struct fsxattr) to make things work on this platform, and then we remove
> the #includes for anything that will get pulled (directly or indirectly)
> by xfs.h for cleanliness. Without this, a user compiling new xfsprogs
> on a system with a 4.7 kernel gets this:
>
> Building scrub
> [CC] disk.o
> In file included from ../include/xfs.h:37:0,
> from disk.c:40:
> ../include/xfs/linux.h:185:8: error: redefinition of 'struct fsxattr'
> struct fsxattr {
> ^~~~~~~
> In file included from disk.c:31:0:
> /usr/include/linux/fs.h:155:8: note: originally defined here
> struct fsxattr {
> ^~~~~~~
> gmake[2]: *** [../include/buildrules:60: disk.o] Error 1
> gmake[1]: *** [include/buildrules:36: scrub] Error 2
> make: *** [Makefile:77: default] Error 2
>
> Reported-by: Mikael Magnusson <mikachu@xxxxxxxxx>
> Signed-off-by: Darrick J. Wong <darrick.wong@xxxxxxxxxx>
mmkay. I guess the question of whether having our own redefined
fsxattr is wise in the first place is a different discussion.
Reviewed-by: Eric Sandeen <sandeen@xxxxxxxxxx>
--
To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
