Created attachment 639908 [details] build log I'm not sure why, but dev-util/android-tools-9.0.0_p3-r1 suddenly fails to rebuild on ppc64 (LE). I'm aware this package lacks ppc64 keywords, but it did work previously (and I discussed whether to submit a bug with zmedico first). My current /usr/lib/debug/usr/bin/mke2fs.android.debug suggests the previous build succeeded using GCC 9.2.0-r2. That same compiler version fails now. GCC 9.3.0 also fails in the same manner. Prior build was with sys-kernel/linux-headers-4.20 installed, but I don't see a significant change between that and the current sys-kernel/linux-headers-5.4.
Downgraded linux-headers and confirmed the older version doesn't help.
Rolling back sys-libs/glibc-2.30-r8 to sys-libs/glibc-2.29-r7 fixes the build...
(In reply to Luke-Jr from comment #2) > Rolling back sys-libs/glibc-2.30-r8 to sys-libs/glibc-2.29-r7 fixes the > build... Did you roll back with a glibc-2.29-r7 binary package, or did you rebuild it? The ebuilds show this patchset change: --- glibc-2.30-r7.ebuild +++ glibc-2.30-r8.ebuild @@ -29,6 +29,6 @@ # Gentoo patchset -PATCH_VER=9 -PATCH_DEV=slyfox +PATCH_VER=10 +PATCH_DEV=dilfridge SRC_URI+=" https://dev.gentoo.org/~${PATCH_DEV}/distfiles/${P}-patches-${PATCH_VER}.tar.xz" It should be these 2 tags: https://gitweb.gentoo.org/fork/glibc.git/log/?h=gentoo/glibc-2.30-9 https://gitweb.gentoo.org/fork/glibc.git/log/?h=gentoo/glibc-2.30-10 The only change is this one patch for i386 (confirmed by comparison of glibc-2.30-patches-9.tar.xz and glibc-2.30-patches-10.tar.xz tarball contents): https://gitweb.gentoo.org/fork/glibc.git/commit/?h=gentoo/glibc-2.30-10&id=e367e3a5e0e3e83bced89867102bbd95f2ca289a
(In reply to Zac Medico from comment #3) > Did you roll back with a glibc-2.29-r7 binary package, or did you rebuild it? No rebuild. The issue seems to be with the glibc version bump itself: bits/statx.h is now opportunistically including linux/stat.h, which declares the conflicting typedefs. (This wasn't a problem with older glibcs, because they never got the linux/stat.h included.) An ugly workaround is to define _LINUX_STAT_H in affected files before including anything else. diff --git a/dev-util/android-tools/android-tools-9.0.0_p3-r1.ebuild b/dev-util/android-tools/android-tools-9.0.0_p3-r1.ebuild index b00003af78a..3eccd2943c1 100644 --- a/dev-util/android-tools/android-tools-9.0.0_p3-r1.ebuild +++ b/dev-util/android-tools/android-tools-9.0.0_p3-r1.ebuild @@ -109,6 +109,16 @@ src_prepare() { -e "s|^(PKGVER =).*|\\1 ${MY_PV}|g" \ -i build.ninja || die + find e2fsprogs '(' -name '*.c' -o -name '*.h' ')' -print0 | + xargs -0 grep '#include <sys/stat\.h>' -l | + while read f; do + { + echo '#define _LINUX_STAT_H' + cat "$f" + } >"$f.new" + mv "$f.new" "$f" + done + # The pregenerated ninja file expects the build/ dir. BUILD_DIR="${CMAKE_USE_DIR}/build" cmake-utils_src_prepare
BTW, note I only tested that this fixes the compile, not necessarily runtime behaviour. I'm not sure how to confirm for sure that using the android_types.h typedefs is the correct thing to do here (but it is what was happening previously). It's possible that it really should be using the native-defined types. On ppc64, `long` and `long long` ARE indeed both 64-bit types, so it SHOULD work either way - but I don't know about other platforms that might have experienced this build failure; it's possible this will silently produce broken code for them.
Is this something that can be worked around like this? CFLAGS=+" -D_LINUX_STAT_H"
(In reply to Zac Medico from comment #6) > Is this something that can be worked around like this? > > CFLAGS=+" -D_LINUX_STAT_H" This seems to work with 31.0.0_p1 at least
Same issue/workaround applies to 31.0.3 still...
(and 33.0.3)
The workaround is quite convenient because you can use package.env to apply it: cat <<EOT >> /etc/portage/env/linux-stat-h CFLAGS="${CFLAGS} -D_LINUX_STAT_H" CXXFLAGS="${CFLAGS}" EOT echo "dev-util/android-tools linux-stat-h" > /etc/portage/package.env/android-tools
