Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Yegor Yefremov via buildroot <buildroot@buildroot.org>
To: buildroot@buildroot.org
Cc: James Hilliard <james.hilliard1@gmail.com>
Subject: [Buildroot] [PATCH v2 2/2] package/python-grpcio: disable for the MIPS n32 ABI
Date: Thu, 17 Sep 2026 13:37:20 +0200	[thread overview]
Message-ID: <20260917113720.1297345-3-yegorslists@gmail.com> (raw)
In-Reply-To: <20260917113720.1297345-1-yegorslists@gmail.com>

From: Yegor Yefremov <yegorslists@googlemail.com>

python-grpcio builds its own bundled copy of abseil-cpp, which only
implements DirectMmap() with mmap2 for the o32 ABI on MIPS:

    #if ... (defined(__mips__) && _MIPS_SIM == _MIPS_SIM_ABI32) || ...

With the n32 ABI, the "remaining 64-bit architectures" fallback is
selected instead, which fails to build because long is 32-bit there:

    third_party/abseil-cpp/absl/base/internal/direct_mmap.h:130:39:
        error: static assertion failed: Platform is not 64-bit
      130 |   static_assert(sizeof(unsigned long) == 8, "Platform is not 64-bit");
          |                 ~~~~~~~~~~~~~~~~~~~~~~^~~~
    third_party/abseil-cpp/absl/base/internal/direct_mmap.h:130:39:
        note: the comparison reduces to '(4 == 8)'

This is the same defect fixed for libabseil-cpp in the previous patch,
but the dependency added there does not help here: python-grpcio does
not use the Buildroot abseil, it compiles the copy bundled in the
tarball.

Using the Buildroot-provided abseil instead is not an option today.
setup.py does have a GRPC_PYTHON_BUILD_SYSTEM_ABSL knob, but it is
hardcoded to the build machine paths:

    if BUILD_WITH_SYSTEM_ABSL:
        CORE_C_FILES = filter(
            lambda x: "third_party/abseil-cpp" not in x, CORE_C_FILES
        )
        ABSL_INCLUDE = (os.path.join("/usr", "include"),)
    [...]
    if BUILD_WITH_SYSTEM_ABSL:
        EXTENSION_LIBRARIES += tuple(
            lib.stem[3:]
            for lib in sorted(pathlib.Path("/usr").glob("lib*/libabsl_*.so"))
        )

i.e. it would pick up the host headers and host libraries, so it cannot
be used when cross-compiling without patching setup.py. And even with
such a patch it would not fix this build failure, since Buildroot's
abseil has the very same limitation.

So just disable the package for the n32 ABI. The o32 and n64 ABIs are
unaffected. Note that n32 is the default ABI for BR2_mips64/BR2_mips64el,
so this affects every mips64 build that does not explicitly select n64.

For the LTS maintainers: python-grpcio gained MIPS support in commit
2bfad952c374, released in 2024.02, and the autobuilders have been hitting
this ever since, already with grpcio 1.60.0, the version shipped in
2024.02:

    https://autobuild.buildroot.net/results/e6cb7f473a28af8b53e7cbb8d8a582adffdeb66e/

It is still reproduced on 2025.02.x:

    https://autobuild.buildroot.net/results/9cf98bff7ce05262d6ff4221953901ae5543880e/

so a backport is needed there.

Fixes: 2bfad952c374258e37ffdf46a2c450d860640e11 ("package/python-grpcio: add BR2_PACKAGE_PYTHON_GRPCIO_ARCH_SUPPORTS")
Fixes:
https://autobuild.buildroot.net/results/90405c0a3d0b2e929d5074305906e6fe3679298c/

Assisted-by: Claude:claude-opus-5
Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
---
 package/python-grpcio/Config.in | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/package/python-grpcio/Config.in b/package/python-grpcio/Config.in
index 6119991c7e..f52e19dc18 100644
--- a/package/python-grpcio/Config.in
+++ b/package/python-grpcio/Config.in
@@ -6,6 +6,11 @@ config BR2_PACKAGE_PYTHON_GRPCIO_ARCH_SUPPORTS
 	default y if BR2_i386 || BR2_x86_64
 	default y if BR2_mips || BR2_mipsel || BR2_mips64 || BR2_mips64el
 	default y if BR2_riscv
+	# The bundled abseil-cpp only implements DirectMmap() for the o32
+	# ABI on MIPS, and its 64-bit fallback fails to build with the n32
+	# ABI, where long is 32-bit. See
+	# third_party/abseil-cpp/absl/base/internal/direct_mmap.h
+	depends on !BR2_MIPS_NABI32
 
 config BR2_PACKAGE_PYTHON_GRPCIO
 	bool "python-grpcio"
-- 
2.34.1

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

  parent reply	other threads:[~2026-09-17 11:38 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-17 11:37 [Buildroot] [PATCH v2 0/2] package/{libabseil-cpp, python-grpcio}: disable for the MIPS n32 ABI Yegor Yefremov via buildroot
2026-09-17 11:37 ` [Buildroot] [PATCH v2 1/2] package/libabseil-cpp: " Yegor Yefremov via buildroot
2026-09-25 14:46   ` Raphaël Mélotte via buildroot
2026-09-17 11:37 ` Yegor Yefremov via buildroot [this message]
2026-09-25 14:46   ` [Buildroot] [PATCH v2 2/2] package/python-grpcio: " Raphaël Mélotte via buildroot
2026-09-18  7:37 ` [Buildroot] [PATCH v2 0/2] package/{libabseil-cpp, python-grpcio}: " Thomas Petazzoni via buildroot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260917113720.1297345-3-yegorslists@gmail.com \
    --to=buildroot@buildroot.org \
    --cc=james.hilliard1@gmail.com \
    --cc=yegorslists@googlemail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox