ccache: FATAL: Could not find compiler "gcc" in PATH

[renning22]

I can't build any linux targets somehow after I upgraded to Bazel 0.5.4.

ERROR: /usr/local/google/home/ningr/.cache/bazel/_bazel_ningr/5cdbcab7751afe004080d5ce1e95b149/external/gflags_git/BUILD.bazel:7:1: C++ compilation of rule '@gflags_git//:gflags' failed (Exit 1): gcc failed: error executing command 
  (cd /usr/local/google/home/ningr/.cache/bazel/_bazel_ningr/5cdbcab7751afe004080d5ce1e95b149/execroot/__main__ && \
  exec env - \
    PWD=/proc/self/cwd \
  /usr/lib/ccache/gcc -U_FORTIFY_SOURCE -fstack-protector -Wall -B/usr/lib/ccache -B/usr/bin -Wunused-but-set-parameter -Wno-free-nonheap-object -fno-omit-frame-pointer -msse4.1 '-std=c++0x' -MD -MF bazel-out/local-fastbuild/bin/external/gflags_git/_objs/gflags/external/gflags_git/src/gflags_reporting.pic.d '-frandom-seed=bazel-out/local-fastbuild/bin/external/gflags_git/_objs/gflags/external/gflags_git/src/gflags_reporting.pic.o' -fPIC -iquote external/gflags_git -iquote bazel-out/local-fastbuild/genfiles/external/gflags_git -iquote external/bazel_tools -iquote bazel-out/local-fastbuild/genfiles/external/bazel_tools -isystem external/gflags_git -isystem bazel-out/local-fastbuild/genfiles/external/gflags_git -isystem external/bazel_tools/tools/cpp/gcc3 -Ibazel-out/local-fastbuild/genfiles/external/gflags_git/gflags -Wno-sign-compare -Wno-unused-local-typedefs -fno-canonical-system-headers -Wno-builtin-macro-redefined '-D__DATE__="redacted"' '-D__TIMESTAMP__="redacted"' '-D__TIME__="redacted"' -c external/gflags_git/src/gflags_reporting.cc -o bazel-out/local-fastbuild/bin/external/gflags_git/_objs/gflags/external/gflags_git/src/gflags_reporting.pic.o)
ccache: FATAL: Could not find compiler "gcc" in PATH
Target //third_party/s2_geometry:s2_geometry failed to build

[hlopko]

Hmm that is strange. I don't think there were any breaking changes in 0.5.4 in this area. From which bazel were you upgrading? Did this really work before?

It seems /usr/lib/ccache/gcc looks for gcc on PATH, but bazel sets it's own PATH for sandboxed actions. You can use --action_env to force passing PATH to actions. There's a doc about this functionality: https://bazel.build/designs/2016/06/21/environment.html

[renning22]

Bazel 0.5.4 doesn't have this problem for me anymore. Sorry for this.

[renning22]

The problem has come back again on my workstation. I looks like when I ssh to workstation it works fine. But when I physically log in workstation it doesn't work. I'm using Fish shell BTW.

[renning22]

--action_env doesn't solve the problem.
We are passing "--spawn_strategy=standalone --genrule_strategy=standalone" from toos/bazel.rc so it's not in sandbox.
Bazel 0.4.5 works well in the same environment.

[renning22]

Found a solution in this thread: #1322 by:
export CC="/usr/bin/gcc"
export CXX="/usr/bin/g++"

Seemed bazel doesn't work well with ccache gcc .

[chenkan0104]

But Bazel should work well with ccache gcc right? So why would this issue be closed? I personally encountered this problem in Bazel 0.8.1 Ubuntu 14.04 just now.

[renning22]

Agree, this should be handled by bazel. Resetting environment variables should only be a workaround.

[yxlao]

Another workaround is to set the bazel PATH with --action_env. This is potentially dangerous since in theory, bazel wants isolation from the system environment to ensure build consistency. In practice, this works in my case with bazel 0.5.4.

Example:

bazel build //your/build/target --action_env=PATH=$PATH

[mapx]

I met with the same issue with Bazel-0.13.0 and solved it by downgrading Bazel to 0.12.0.

[hlopko]

In this case the proper thing to do is to properly specify PATH with --action_env. Apparently (without looking deeply into this) bazel 0.13. stopped letting system PATH through to actions.

[hlopko]

CC @ulfjack

[ulfjack]

My hypothesis is that the CppCompileAction is forwarding env variables if they're set to a fixed value, but not forwarding env variables if they're supposed to be inherited.

[ulfjack]

Yep, see here:
https://source.bazel.build/bazel/+/master:src/main/java/com/google/devtools/build/lib/rules/cpp/CppCompileActionBuilder.java;l=125

This should call getActionEnvironment not getLocalShellEnvironment, and also forward that to the underlying AbstractAction.

[ulfjack]

CppLinkAction is also broken. It calls getLocalShellEnvironment and getVariableShellEnvironment (combining both is effectively the same as getActionEnvironment). However, it then drops the variable shell environment. Its getEnvironment method is simply wrong (and it can't do the correct thing by design).

[ulfjack]

I submitted 1b333a2, which should fix this. Can you verify with a bazel binary built from head?

[PapaMadeleine2022]

export CC="/usr/bin/gcc" works

[jgallucci32]

Had to add CC=/usr/bin/gcc on a RHEL8 system using bazel 3.7.1. Guess this is still an issue.

[zimonitrome]

I am still having problems with this running Bazel with MSYS2 on Windows 11.

I can run bazel build fine until it encounters either gcc or g++ as cmd instructions in the BUILD file.

I tried

export CC="/usr/bin/gcc"
export CXX="/usr/bin/g++"

in both MSYS2 shell, in the BUILD file, and using set in Windows before running the Bazel command.

I also tried

bazel build //your/build/target --action_env=PATH=$PATH

but it seemingly has no effect.

I felt like I came really close to getting this all to work just to stumble at the finish line :/