Jiri Daněk

@coolxv I use Thread Sanitizer for unit tests. I think that putting `__attribute__((no_sanitize("thread")))` on `Stub::set` is reasonable. I am also thinking that maybe the Sanitizer error is actually a sanitizer...

Retrying with newer GCC might resolve the warning. I saw this warning in my project with GCC 8.5 and it went away when I use GCC 12. Looking at the...

My guess is that bazel sandboxing is blocking access. If that is the case, try building with ` --sandbox_writable_path=$HOME/.ccache` Your workaround using `sudo` suggests sandboxing may not be to blame,...

It is usually useful to run bazel with `-s --sandbox_debug --verbose_failures` and include the output from this.

>so I guess `chown` should make no difference, am I missing anything? Your reasoning makes sense. I just personally prefer one bold try with `chown` over doing much up-front thinking...

BTW, bazel has a background daemon. It is sometimes useful to kill it and restart it, because it might be remembering some now out-of-date state, with `bazel shutdown`. Probably not...

In that case, what does using the sandbox writable path argument, that is `--sandbox_writable_path=$HOME/.ccache` do?

Awesome. That's expected behavior. Sandboxing limits the writable paths the build can write into. If you want ccache to work from inside a Bazel build with sandboxing turned on, you...

You can create config file `$HOME/.bazelrc` with the option, https://docs.bazel.build/versions/master/guide.html#bazelrc-syntax-and-semantics.

build --sandbox_writable_path=/home/user/.ccache in bazel.rc should work. What does not work is using env variables, such as `$HOME` in .bazel.rc. https://github.com/bazelbuild/bazel/issues/10904. And env variables there never worked, as far as I...