Arch Linux User Repository

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

@npreining Alright then, I'll include a fix for your use case in the next update.

Thanks @Nocifer, yes I have ANDROID_NDK_HOME set due to having android-ndk installed which ships /etc/profile.d/android-ndk.sh.

Unsetting the env vars before trying to update the build has worked. Thanks a lot for the pointer, much appreciated!

@npreining Do you by any chance do any Android development work or some such? As far as I understand the hacky solution introduced by Mozc's devs to solve this Bazel error (hacky because it can only be really fixed when Bazel addresses the issue on its end) you should no longer be getting an error about the Android NDK unless the ANDROID_NDK_HOME environment variable is set in your PATH, in which case the setup process will try to pull an Android NDK from the path provided by ANDROID_NDK_HOME (/opt/android-ndk/platforms in your case).

If you do have this env var set and you need it that way, then you should just comment out line 18 in WORKSPACE.bazel (and maybe line 16 as well) and check if Mozc will build. If so, then I'll reintroduce the NDK fix I removed with this update and report to upstream about it.

Tried to compile (via yay) but got error. bazel cache is cleaned before the build, as well as all clean build enabled. Error is about finding android:

==> Making package: mozc-ut 2.28.4800.102.20220723-1 (Mon Jul 25 10:22:22 2022)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> WARNING: Using existing $srcdir/ tree
==> Starting build()...
Extracting Bazel installation...
Starting local Bazel server and connecting to it...
ERROR: /home/norbert/.cache/yay/mozc-ut/src/mozc-ut-git/src/WORKSPACE.bazel:19:18: fetching android_ndk_repository rule //external:androidndk: java.io.IOException: Expected directory at /opt/android-ndk/platforms but it is not a directory or it does not exist. Unable to read the Android NDK at /opt/android-ndk, the path may be invalid. Is the path in android_ndk_repository() or ANDROID_NDK_HOME set correctly? If the path is correct, the contents in the Android NDK directory may have been modified.
ERROR: Analysis of target '//gui/tool:mozc_tool' failed; build aborted: Expected directory at /opt/android-ndk/platforms but it is not a directory or it does not exist. Unable to read the Android NDK at /opt/android-ndk, the path may be invalid. Is the path in android_ndk_repository() or ANDROID_NDK_HOME set correctly? If the path is correct, the contents in the Android NDK directory may have been modified.
INFO: Elapsed time: 11.246s
INFO: 0 processes.
FAILED: Build did NOT complete successfully (6 packages loaded, 6 targets configured)
    currently loading: @bazel_tools//tools/jdk
    Fetching @local_jdk; fetching
    Fetching @local_config_cc_toolchains; Restarting.
==> ERROR: A failure occurred in build().

Thanks for your work on mozc!

Cleared cache and i got the following error at the end of the compiliation :

In file included from /usr/lib/gcc/x86_64-pc-linux-gnu/12.1.0/../../../../include/c++/12.1.0/string:45,
                 from ./data_manager/data_manager.h:35,
                 from data_manager/data_manager.cc:30:
/usr/lib/gcc/x86_64-pc-linux-gnu/12.1.0/../../../../include/c++/12.1.0/bits/stl_iterator_base_types.h:127:34: note: declared here
  127 |     struct _GLIBCXX17_DEPRECATED iterator
      |                                  ^~~~~~~~
ERROR: /home/admin/.cache/yay/mozc-ut/src/mozc-ut-git/src/data_manager/oss/BUILD.bazel:45:13: Executing genrule //data_manager/oss:mozc_dataset_for_oss@dictionary failed: (Aborted): bash failed: error executing command /bin/bash -c ... (remaining 1 argument skipped)

Use --sandbox_debug to see verbose messages from the sandbox and retain the sandbox build root for debugging
terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc

Edit : Caused by global use of Hardened_malloc Allocator in non normal variant.

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

@LetMeByte Yeah, ccache et al still remain largely incompatible with Bazel. I think the obvious and even easier solution to this would be to add BUILDENV=(!distcc !ccache) in the PKGBUILD so as to explicitly disable both of them, even if the user has manually enabled them in makepkg.conf. Is that what you meant by "setting a compatible toolchain"?

The funny thing is, more than one times in the past I've proposed this solution to other AUR maintainers for them to use in their packages in order to fix this exact same issue, but apparently I failed to ever realize it could also be used to solve the issue in my own package as well :P

Anyway, I'll do it in the next update.

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

UPDATE: @Nocifer: Thank you for the quick response, the solution you suggested is definitely the best way.

@Nocifer

Thank you for the highly detailed comment and the untold (but appreciated) hours of work you put in for little old me.

As previously mentioned I am not overburdened with an excess of brain cells, so I won't try to "[delete] the package cache" because I will somehow manage to rm rf --no-preserve-root / or chmod -x chmod or something, and I need this laptop for work. Instead, I will continue to daily drive my laptop and report back after a couple of updates.

Of couse, I have no doubt that your newfound expertise has not been misplaced and my issue has been resolved, so once again I'd like to extend my thanks.

After digging around a bit I believe I've found the culprit. Turns out that whenever the PATH is modified, Bazel will unconditionally invalidate its cache, even if the newly assigned PATH value is the same as before. I've changed the PKGBUILD to use a Java-specific variable that allows Bazel to find and use Java 11 without touching the PATH, so now the cache works as intended.

The bad news is that the first time you try to rebuild the package using the new PKGBUILD, from Bazel's perspective the PATH will once again be modified (from the previously used "/usr/lib/jvm/java-11-openjdk/bin/:$PATH" to the default PATH) so the cache will once again become invalidated; but on the next and subsequent rebuilds it will not, and from then on only the modified files will need to be recompiled on package updates.

The good news is that with this next update I was already planning to replace mozc-ut-common with mozc-ut, which means that Bazel will need to do a full recompile anyway, regardless of the cache issues, because mozc-ut is a completely new package. So one way or another, you guys won't be spared the full recompile. Oh, sorry, this was supposed to be the good news :)

@asday, thanks for taking the time to mention this issue, it ended up becoming the catalyst for an arguably very good improvement (not to mention that I've had the opportunity to learn some interesting things about how Bazel works internally). Also, if you wish to test and verify that the cache now works properly, then as soon as you finish with the update you can force a rebuild by deleting the package cache and then reinstalling Mozc - hopefully, this time the compilation step should only take a handful of seconds at most (because nothing will be recompiled).

EDIT: Unfortunately, TIL that the replaces field in the PKGBUILD apparently does not work for AUR packages, and the only way to automatically replace an installed AUR package is to merge it into its replacement. But I'd already pushed the new updates before I learned that, so it's going to be two full recompiles in the space of a few days (one for mozc-ut-common now, and one for mozc-ut when the merge goes ahead). What fun.