Hi,

Currently bazel-bootstrap in Debian does not support 32 bit arches [1].
Mozc 3 (mozc 2 is in unstable now) will use bazel for its build system.
If mozc cannot be built on 32 bit arches, we may not have a working
Japanese input method on 32 bit arches (the future of anthy is
uncertain). Please consider supporting 32 bit arches.

[1] https://buildd.debian.org/status/package.php?p=bazel-bootstrap

Hi Luke,

Thanks for the bug report!
I'm not sure if that is possible. The 64-bit dependency is (or was when
I first packaged the old version of Bazel) tied to Bazel's design. We're
having a conversation on our discussion list [1] about this issue and
whether or not it applies to the newest version of Bazel that Paul
recently uploaded to Debian. Feel free to follow along there if you're
interested.

One way or the other, we'll update this bug report with the results of
that conversation.

Again, thanks for bringing up the request!

Best regards,
-Olek

[1] https://lists.debian.org/debian-bazel/2026/07/msg00002.html

Hi all,


I've been research this for a while. I remove architecture-is-64-bit in
Build-Depends and build it in i386 environment. And now I know why it is
not working.



## Heap size

First, in debian/rules


export BAZEL_JAVAC_OPTS = -J-Xmx4096m
--add-opens=java.base/java.nio=ALL-UNNAMED 
--add-opens=java.base/java.lang=ALL-UNNAMED -proc:full 
-Acom.google.auto.value.AutoBuilderIsUnstable


causes failure because -Xmx4096m is too large for 32-bit platforms.
Because on 32-bit platform the memory address is only 4GB. So e can
change it to


BAZEL_JAVAC_OPTS = --add-opens=java.base/java.nio=ALL-UNNAMED \
                    --add-opens=java.base/java.lang=ALL-UNNAMED \
                    -proc:full \
                    -Acom.google.auto.value.AutoBuilderIsUnstable
ifeq ($(DEB_HOST_ARCH_BITS),32)
     export BAZEL_JAVAC_OPTS := -J-Xmx1536m $(BAZEL_JAVAC_OPTS)
else
     export BAZEL_JAVAC_OPTS := -J-Xmx4096m $(BAZEL_JAVAC_OPTS)
endif


## mmap

And then we will met the following error

In src/tools/singlejar/mapped_file_posix.inc


// The implementation is specific to 64-bit Linux / OS X / BSD.
#if !((defined(__linux__) || defined(__APPLE__) || defined(__FreeBSD__) || \
        defined(__OpenBSD__)) &&                 \
       __SIZEOF_POINTER__ == 8)
#error This code for 64 bit Unix.
#endif


This is because in bazel it uses mmap to map file to memory. And if it
maps some files larger than 4GB, we will have some problems here. But it
is ok if we add (__SIZEOF_POINTER__ == 8 || __SIZEOF_POINTER__ == 4) to
just let it pass.


## bazel rules

And then we will meet the most uncomfortable issues here.

rules-java will be fail because it cannot find jni_md.h.

And this is just caused by those bazel rules. Based on how we add
loongson support, that means we might look into bazel-rules-cc,
bazel-rules-java and bazel-platforms. Previously Dandan Zhang make a
patch for bazel-bootstrap to support loong64 when we were at version 4.
But that patch has been splitted to 4. And applied to bazel-bootstrap,
bazel-rules-cc, bazel-rules-java and bazel-platforms. It seems that we
have to do this again.

And if we look at the upstream, the mainline, it seems to me that we
have some technical debt there for loong64. We might need to submit
these patches first to the upstream.

For i386 and armhf, we might need to go through the same procedure again.


Yours,

Paul