Arch Linux User Repository

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

@mitori Well, considering I just built the package fine on my system in a clean chroot, I think I'm gonna have to go with "it's probably on you". The log output you posted suggests that Bazel can't find GCC, so either you've forgotten to install the base-devel group of packages (which is an implicit dependency for all AUR packages) or you've somehow messed up your build environment (e.g. your $PATH).

Auto-Configuration Error: Cannot find gcc or CC; either correct your path or set the CC environment variable
ERROR: /home/archdeck/Downloads/mozc/src/mozc-git/src/server/BUILD.bazel:48:15: //server:mozc_server depends on @local_config_cc//:cc-compiler-k8 in repository @local_config_cc which failed to fetch. no such package '@local_config_cc//': 
Auto-Configuration Error: Cannot find gcc or CC; either correct your path or set the CC environment variable
ERROR: Analysis of target '//server:mozc_server' failed; build aborted: Analysis failed

I have tried building this package with makepkg on 3 arch-based systems and it doesn't work. I wonder if it's on me because I'm doing something wrong or is the package outdated and doesn't work with the latest bazel?

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

Building mozc(-ut) with distcc/ccache installed results in various errors.

The problem is caused by distcc/ccache exporting their own versions of GCC and Clang, check with which gcc or which clang.

The temporary fix is to disable the corresponding options in /etc/makepkg.conf, or just setting the CC environment variable to the standalone version of GCC or Clang:

export CC=/usr/bin/gcc or export CC=/usr/bin/clang

Cool, that really helped with the problem. I also had to delete the cache from pacman though. Then it worked.

Many thanks. :)

These errors are because the recently updated GCC 11.2 toolchain has some internal changes that make cached files from previous builds with older GCC versions no longer valid. Just delete your Bazel cache folder and it should work.

Build fails during installation for me with the following error:

/home/renny/.cache/yay/mozc/src/mozc-git/src/dictionary/file/BUILD.bazel:131:16: Compiling dictionary/file/codec_factory.cc [for host] failed: undeclared inclusion(s) in rule '//dictionary/file:codec_factory':
this rule is missing dependency declarations for the following files included by 'dictionary/file/codec_factory.cc':
  '/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/include/stdint.h'
  '/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/include-fixed/limits.h'
  '/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/include-fixed/syslimits.h'
  '/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/include/stddef.h'
  '/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/include/stdarg.h'
INFO: Elapsed time: 12.803s, Critical Path: 4.26s
INFO: 9 processes: 9 internal.
FAILED: Build did NOT complete successfully
==> ERROR: A failure occurred in build().
    Aborting...
 -> error making: mozc

I'm guessing some file directive could be edited to add the dependency declarations it is missing, but I'm not really a C or C++ expert, so I don't know what to do in this case: if it is an issue with the PKGBUILD or with the program's build script. If it is the later then I'm guessing it would be better to open an issue on GitHub instead? :)

@ruahcra Indeed; and when we're talking about an "old commit", we're really talking about a 3-year old version which still depends on deprecated stuff like gtk2 and python2 and a deprecated build procedure/system (for better or worse, upstream has switched out Ninja for Bazel since a few months ago).

Also, yeah, Mozc only releases new versions by commit (internally they're tagged as such and the version is incremented with almost each new commit, but there are no explicitly tagged releases) so it's up to the maintainer to keep up and update the package accordingly, just like with any other package really.

Regarding the UT dictionary, Mozc is the open source version of Google Japanese Input, which is a top-quality Japanese IME (along the lines of Google Keyboard et al). But Mozc being open source unfortunately means that it doesn't come with the extensive dictionaries/definitions that actually make Google Japanese Input what it is, because Google has chosen to keep them as closed source (possibly to hold an advantage over its competition). So what the UT dictionary does is bring the open source Mozc (closer) to the quality of its closed source cousin by patching the bundled dictionaries and expanding them.

There are some people that for whatever reason do not seem to care for the UT dictionary (or seemingly even for plain Mozc/IBus, seeing as even this vanilla package isn't part of the official Arch repos as IMHO it should) but as I said in the previous comment, I just now realized that since in my version of the packages Mozc has been split into its own base package, ibus-mozc-ut is actually nothing more but plain old ibus-mozc - the UT part only concerns the base Mozc package. So it could be made that there is only one version each of ibus-mozc, emacs-mozc, fcitx-mozc, fcitx5-mozc etc in the AUR, and two choices for the base Mozc part: mozc and mozc-ut, both of which the individual packages would be compatible with, and so the choice would be left to the user on whether to use UT or not. This way I think everybody would be happy.

So both packages build from the same upstream source, but apart from the additional dictionaries they include, the only difference is that this package is stuck on a old commit, where-as ibus-mozc-ut is using a more recent commit?

Also since mozc does not tag releases then it is up to the PKGBUILD maintainer to update the package at an appropriate commit in order to keep it up to date?

In that case I hope you are successful in getting ownership of this package! I will be moving to ibus-mozc-ut for the time being.