Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 723528 - dev-util/android-tools-9.0.0_p3-r1: /usr/include/asm-generic/int-l64.h:29:25: error: conflicting types for ‘__s64’
Summary: dev-util/android-tools-9.0.0_p3-r1: /usr/include/asm-generic/int-l64.h:29:25:...
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: PPC64 Linux
: Normal normal (vote)
Assignee: Zac Medico
Depends on:
Blocks: 876394
  Show dependency tree
Reported: 2020-05-18 03:01 UTC by Luke-Jr
Modified: 2023-03-14 20:16 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---

build log (build.log,311.33 KB, text/plain)
2020-05-18 03:01 UTC, Luke-Jr

Note You need to log in before you can comment on or make changes to this bug.
Description Luke-Jr 2020-05-18 03:01:44 UTC
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/ 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.
Comment 1 Luke-Jr 2020-05-18 03:07:08 UTC
Downgraded linux-headers and confirmed the older version doesn't help.
Comment 2 Luke-Jr 2020-05-25 17:58:07 UTC
Rolling back sys-libs/glibc-2.30-r8 to sys-libs/glibc-2.29-r7 fixes the build...
Comment 3 Zac Medico gentoo-dev 2020-05-25 18:34:33 UTC
(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

It should be these 2 tags:

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):
Comment 4 Luke-Jr 2020-05-25 20:40:03 UTC
(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 || 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"
+		} >"$"
+		mv "$" "$f"
+	done
 	# The pregenerated ninja file expects the build/ dir.
Comment 5 Luke-Jr 2020-05-25 20:44:40 UTC
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.
Comment 6 Zac Medico gentoo-dev 2021-02-11 06:12:53 UTC
Is this something that can be worked around like this?

Comment 7 Luke-Jr 2021-07-30 13:37:12 UTC
(In reply to Zac Medico from comment #6)
> Is this something that can be worked around like this?

This seems to work with 31.0.0_p1 at least
Comment 8 Luke-Jr 2022-01-09 01:09:24 UTC
Same issue/workaround applies to 31.0.3 still...
Comment 9 Luke-Jr 2022-10-17 13:17:43 UTC
(and 33.0.3)
Comment 10 darkbasic 2023-02-16 08:43:48 UTC
The workaround is quite convenient because you can use package.env to apply it:

cat <<EOT >> /etc/portage/env/linux-stat-h

echo "dev-util/android-tools linux-stat-h" > /etc/portage/package.env/android-tools