Arch Linux User Repository

If you're getting compilation errors, please delete your Bazel cache (~/.cache/bazel by default).

Fixed: unlike bazel, bazelisk does not implicitly pull unzip so we need to pull it explicitly.

Fails to build in a clean chroot at the package() step due to:

/startdir/PKGBUILD: line 93: unzip: command not found

Need to add unzip to makedepends to fix.

@jaro3 Your error is a typical example of an outdated Bazel cache that can be fixed by deleting ~/.cache/bazel (or an equivalent non-default path). "Typical" as in, there were some people just the other day who were getting the exact same error with the fcitx-mozc-ut package, and they successfully resolved it by deleting Bazel's cache.

Are you sure you're trying to build in a clean chroot? Did you create the chroot from scratch? If you've used it even once before your testing, then Bazel's cache inside the chroot will not be cleaned before running the build.

Fails to build even in clean chroot:

==> Starting build()...
Starting local Bazel server (8.2.1) and connecting to it...
INFO: Analyzed 3 targets (165 packages loaded, 11017 targets configured).
ERROR: /usr/src/tmp/ibus-mozc/src/mozc/src/unix/ibus/BUILD.bazel:98:16: Compiling unix/ibus/ibus_wrapper.cc failed: absolute path inclusion(s) found in rule '//unix/ibus:ibus_wrapper':
the source file 'unix/ibus/ibus_wrapper.cc' includes the following non-builtin files with absolute paths (if these are builtin files, make sure these paths are in your toolchain):
  '/usr/lib/gcc/x86_64-pc-linux-gnu/15.1.1/include/stddef.h'
  '/usr/lib/gcc/x86_64-pc-linux-gnu/15.1.1/include/limits.h'
  '/usr/lib/gcc/x86_64-pc-linux-gnu/15.1.1/include/syslimits.h'
  '/usr/lib/gcc/x86_64-pc-linux-gnu/15.1.1/include/float.h'
  '/usr/lib/gcc/x86_64-pc-linux-gnu/15.1.1/include/stdarg.h'
  '/usr/lib/gcc/x86_64-pc-linux-gnu/15.1.1/include/stdint.h'
Use --verbose_failures to see the command lines of failed build steps.
INFO: Elapsed time: 9.454s, Critical Path: 2.54s
INFO: 9 processes: 1049 action cache hit, 9 internal.
ERROR: Build did NOT complete successfully
==> ERROR: A failure occurred in build().
    Aborting...
==> ERROR: Makepkg was unable to build ibus-mozc.

Sorry for the fsck up, I don't even know how I managed to do that. Package permissions have (hopefully) been fixed.

Ibus doesn't see mozc after updating for some reason. Changing file permissions to 755 didn't work

The latest version seems to be broken. Cross-referencing a comment under the mozc package, I'm guessing it's due to the change in file permission for the targets mozc-renderer and ibus_mozc from 755 to 644. Changing them back to 755 in the PKGBUILD fixed it for me. Could you please fix these file permission issues? Thank you!

@mod20 I get the same build error even when building against the latest master. I've reported it upstream, so hopefully it'll get fixed soon.

I am getting the following error when compiling with latest GCC (13.1.1):

ERROR: /home/modanese/.cache/aurutils/sync/ibus-mozc/src/ibus-mozc-git/src/unix/ibus/BUILD.bazel:85:16: Compiling unix/ibus/ibus_wrapper.cc failed: (Exit 1): gcc failed: error executing command (from target //unix/ibus:ibus_wrapper) /usr/bin/gcc -U_FORTIFY_SOURCE -fstack-protector -Wall -Wunused-but-set-parameter -Wno-free-nonheap-object -fno-omit-frame-pointer -g0 -O2 '-D_FORTIFY_SOURCE=1' -DNDEBUG -ffunction-sections ... (remaining 60 arguments skipped)

Use --sandbox_debug to see verbose messages from the sandbox and retain the sandbox build root for debugging
unix/ibus/ibus_wrapper.cc: In member function 'void mozc::ibus::IbusBusWrapper::RequestName(absl::lts_20230125::string_view)':
unix/ibus/ibus_wrapper.cc:417:13: error: 'uint32_t' does not name a type
  417 |   constexpr uint32_t flags = 0;
      |             ^~~~~~~~
unix/ibus/ibus_wrapper.cc:31:1: note: 'uint32_t' is defined in header '<cstdint>'; did you forget to '#include <cstdint>'?
   30 | #include "unix/ibus/ibus_wrapper.h"
  +++ |+#include <cstdint>
   31 | 
unix/ibus/ibus_wrapper.cc:418:44: error: 'flags' was not declared in this scope
  418 |   ibus_bus_request_name(bus_, name.data(), flags);
      |                                            ^~~~~

Tried deleting the bazel cache, but that didn't help.

Sorry about that, my cache folder still contained a mozc_renderer binary in renderer from the previous build and during testing the package managed to build successfully by reusing that, so I completely failed to notice the issue. Should be fixed now, thanks for reporting.