xfsprogs: only partially picks up sys-kernel/linux-headers upgrade? |
|||
Issue descriptionSee this tryjob, for example: https://cros-goldeneye.corp.google.com/chromeos/healthmonitoring/buildDetails?buildbucketId=8936271957343192448 Upgrading linux-headers: https://chromium-review.googlesource.com/c/chromiumos/overlays/chromiumos-overlay/+/1191991 is giving xfsprogs problems: /bin/sh ../libtool --quiet --tag=CC --mode=compile x86_64-cros-linux-gnu-clang -O2 -pipe -O2 -pipe -march=corei7 -g -fno-exceptions -fno-unwind-tables -fno-asynchronous-unwind-tables -D_FILE_OFFSET_BITS=64 -I. -O2 -pipe -O2 -pipe -march=corei7 -g -fno-exceptions -fno-unwind-tables -fno-asynchronous-unwind-tables -DNDEBUG -DVERSION=\"4.14.0\" -DLOCALEDIR=\"/usr/share/locale\" -DPACKAGE=\"xfsprogs\" -I../include -I../libxfs -D_GNU_SOURCE -funsigned-char -fno-strict-aliasing -Wall -DHAVE_MNTENT -DHAVE_FSETXATTR -DENABLE_BLKID -DHAVE_GETFSMAP -c xfs_dir2_sf.c xfsprogs-4.14.0-r1: In file included from crc32.c:37: xfsprogs-4.14.0-r1: In file included from ../include/xfs.h:37: xfsprogs-4.14.0-r1: ../include/xfs/linux.h:226:11: fatal error: 'linux/fsmap.h' file not found xfsprogs-4.14.0-r1: # include <linux/fsmap.h> xfsprogs-4.14.0-r1: ^~~~~~~~~~~~~~~ The problem is that the compiler headers (cross-x86_64-cros-linux-gnu/linux-headers) aren't getting upgraded, while the board root headers (sys-kernel/linux-headers) do. So the ./configure stage picked up the new <linux/fsmap.h> in /build/$BOARD/usr/include/ (and so we define HAVE_GETFSMAP), but the compile stage is picking up headers from /usr/x86_64-cros-linux-gnu/usr/include (where we don't yet have <linux/fsmap.h>). I can fix this by manually forcing an extra -I/build/$BOARD/... arg to the compile line, but that obviously isn't a workable solution. Do you folks have any suggestions here? Should I be forcing an upgrade of the "toolchain" linux-headers along with this? Or am I missing something about the compile stage, such that it should have a larger -I<include> path? As an aside: my first attempt at this seems a little misguided: https://chromium-review.googlesource.com/c/chromiumos/overlays/portage-stable/+/1199879 xfsprogs *can* build without a recent linux-headers -- but it doesn't work out if it's pulling from different headers in configure vs. compile stages.
,
Sep 6
I updated this CL: https://chromium-review.googlesource.com/c/chromiumos/overlays/portage-stable/+/1199879
,
Oct 5
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/overlays/portage-stable/+/69210e695791947286bd558a4bae94f49081bae3 commit 69210e695791947286bd558a4bae94f49081bae3 Author: Brian Norris <briannorris@chromium.org> Date: Fri Oct 05 22:43:28 2018 xfsprogs: don't assume $BUILD_CC has fsmap.h just because $CC does 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. Move -DHAVE_GETFSMAP from $(PCFLAGS) (which gets used by both $BUILD_CC and $CC) to $(CFLAGS) (which is only used by $CC). Patch is submitted upstream at: http://lkml.kernel.org/m/20180906183529.117251-1-briannorris@chromium.org Submitted gentoo PR here, since maintainer is slow: https://github.com/gentoo/gentoo/pull/10070 BUG= chromium:881145 TEST=precq, with and without upgraded linux-headers Change-Id: Ief87748d7ae2374db6dfd35348ab02b643d90678 Signed-off-by: Brian Norris <briannorris@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1199879 Reviewed-by: Chirantan Ekbote <chirantan@chromium.org> [add] https://crrev.com/69210e695791947286bd558a4bae94f49081bae3/sys-fs/xfsprogs/xfsprogs-4.14.0-r1.ebuild [add] https://crrev.com/69210e695791947286bd558a4bae94f49081bae3/sys-fs/xfsprogs/files/xfsprogs-4.14.0-BUILD_CC-fsmap.patch [modify] https://crrev.com/69210e695791947286bd558a4bae94f49081bae3/sys-fs/xfsprogs/xfsprogs-4.14.0.ebuild
,
Oct 5
|
|||
►
Sign in to add a comment |
|||
Comment 1 by briannorris@chromium.org
, Sep 6Ugh, so I figured out what the problem is... xfsprogs is doing a host compilation with $BUILD_CC and $BUILD_CFLAGS, so the host ("*-pc-*") toolchain is purposely not going to pick up SYSROOT=/build/${BOARD} it seems. Also, the parallel build was misleading -- it's this line that fails, not the one I quoted: x86_64-pc-linux-gnu-clang -O2 -pipe -O2 -pipe -march=corei7 -g -fno-exceptions -fno-unwind-tables -fno-asynchronous-unwind-tables -D_FILE_OFFSET_BITS=64 -DNDEBUG -DVERSION=\"4.14.0\" -DLOCALEDIR=\"/usr/share/locale\" -DPACKAGE=\"xfsprogs\" -I../include -I../libxfs -DENABLE_GETTEXT -D_GNU_SOURCE -funsigned-char -fno-strict-aliasing -Wall -DHAVE_MNTENT -DHAVE_FSETXATTR -DENABLE_BLKID -DHAVE_GETFSMAP -v -D CRC32_SELFTEST=1 crc32.c -o crc32selftest Notice the different choice in compiler. The following hack works for me, by effectively moving HAVE_GETFSMAP from $PCFLAGS (which goes into both $CFLAGS and $BUILD_CFLAGS) into just $CFLAGS. It looks like the handling of autoconf for BUILD_CFLAGS in general is a bit wanting -- it assumes that the HAVE_* flags determined for $CC are also true for $BUILD_CC. diff --git a/sys-fs/xfsprogs/xfsprogs-4.14.0.ebuild b/sys-fs/xfsprogs/xfsprogs-4.14.0.ebuild index 1dd2cfc2ee46..f76a9136c6db 100644 --- a/sys-fs/xfsprogs/xfsprogs-4.14.0.ebuild +++ b/sys-fs/xfsprogs/xfsprogs-4.14.0.ebuild @@ -48,6 +48,7 @@ src_prepare() { sed -i \ -e "/^PKG_DOC_DIR/s:@pkg_name@:${PF}:" \ -e "1iLLDFLAGS += $(usex static '-all-static' '')" \ + -e '/^PCFLAGS.*-DHAVE_GETFSMAP$/s:^P::' \ include/builddefs.in || die find -name Makefile -exec \ sed -i -r -e '/^LLDFLAGS [+]?= -static(-libtool-libs)?$/d' {} + I guess I'll try to propose something like that upstream and link to it on our Gerrit...