The $BUILD_CC toolchain might have an older set of Linux headers than
the $CC toolchain. It's generally unsafe to try to build both with the
same definitions, but in particular, this one can cause compilation
failures in the local crc32selftest build:
In file included from crc32.c:37:
In file included from ../include/xfs.h:37:
../include/xfs/linux.h:226:11: fatal error: 'linux/fsmap.h' file not found
# include <linux/fsmap.h>
^~~~~~~~~~~~~~~
It's safe to always assume that the headers don't have getfsmap, since
the alternative just includes our local definitions anyway.
Signed-off-by: Brian Norris <briannorris@xxxxxxxxxxxx>
---
This isn't exactly a pretty solution, but it fixes cross-compilation
problems I'm seeing.
include/builddefs.in | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/builddefs.in b/include/builddefs.in
index f7d39a4e4094..209abe1d84dd 100644
--- a/include/builddefs.in
+++ b/include/builddefs.in
@@ -156,8 +156,9 @@ endif
ifeq ($(NEED_INTERNAL_FSXATTR),yes)
PCFLAGS+= -DOVERRIDE_SYSTEM_FSXATTR
endif
+# Don't assume $BUILD_CC has getfsmap just because $CC does.
ifeq ($(HAVE_GETFSMAP),yes)
-PCFLAGS+= -DHAVE_GETFSMAP
+CFLAGS+= -DHAVE_GETFSMAP
endif
LIBICU_LIBS = @libicu_LIBS@
--
2.19.0.rc2.392.g5ba43deb5a-goog
