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

Created on 30 Aug 2017  路  16Comments  路  Source: bazelbuild/bazel

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
P3 feature request

Most helpful comment

Found a solution in this thread: https://github.com/bazelbuild/bazel/issues/1322 by:
export CC="/usr/bin/gcc"
export CXX="/usr/bin/g++"

Seemed bazel doesn't work well with ccache gcc .

All 16 comments

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

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

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.

--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.

Found a solution in this thread: https://github.com/bazelbuild/bazel/issues/1322 by:
export CC="/usr/bin/gcc"
export CXX="/usr/bin/g++"

Seemed bazel doesn't work well with ccache gcc .

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.

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

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

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

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.

CC @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.

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.

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).

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

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

Was this page helpful?
0 / 5 - 0 ratings