C++ code fails to build with clang 4.0 #3977

ulfjack · 2017-10-27T05:30:01Z

On a Ubuntu 17.04 machine, with clang-4.0 installed, I get this error from Bazel for some straightforward C++ code:

this rule is missing dependency declarations for the following files included by 'C-Source/something/other.c':
  '/usr/lib/llvm-4.0/lib/clang/4.0.0/include/stdbool.h'
  '/usr/lib/llvm-4.0/lib/clang/4.0.0/include/stdint.h'
  '/usr/lib/llvm-4.0/lib/clang/4.0.0/include/stddef.h'

The text was updated successfully, but these errors were encountered:

ulfjack · 2017-10-27T05:31:13Z

Failing command line:

$ CC=clang-4.0 bazel run -c opt --copt=-O2 :main

It works with clang-3.9:

$ CC=clang-3.9 bazel run -c opt --copt=-O2 :main

ulfjack · 2017-10-27T05:31:54Z

The -c and --copt parameters are not relevant. Same behavior without them.

benjaminp · 2017-10-27T07:26:42Z

I think this is due to a Debian/Ubuntu patch that results in the clang installation system include directory being realpathed in the output of -v but not -MD.

davido · 2017-10-27T09:57:10Z

FYI: Bazel cannot be built on GCC 7 too: #3903.

nicolasnoble · 2018-02-15T15:11:05Z

Is there any bug entered in the Debian bug system about that if we believe this is on them?

ulfjack · 2018-02-15T15:36:06Z

Good point. I don't think we have.

nicolasnoble · 2018-02-16T12:08:04Z

Can I provide help in any way? This is currently a fairly big issue for us grpc folks. The link to the Debian patch provided by @benjaminp seems to be a 404 for me. If you an point me at the exact source of the problem in terms of actual patches links, I can start bugging Debian maintainers about it.

ulfjack · 2018-02-16T13:35:09Z

It might be due to the bugfix for https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=855222

ulfjack · 2018-02-16T13:36:20Z

Note that I haven't double-checked @benjaminp's statement, but he's usually right about these things.

ulfjack · 2018-02-16T14:31:06Z

Marcel has a possible fix at https://bazel-review.googlesource.com/c/bazel/+/39872.

hlopko · 2018-02-16T15:14:06Z

Hmm cannot repro.

ulfjack · 2018-02-16T16:33:23Z

I still get errors with that patch

this rule is missing dependency declarations for the following files included by 'third_party/mersenne/random.c':
  '/usr/lib/clang/4.0.1/include/stdint.h'

ulfjack · 2018-02-16T16:36:19Z

Here's a snippet from the CROSSTOOL file:

  cxx_builtin_include_directory: "/usr/include/c++/7.2.0"
  cxx_builtin_include_directory: "/usr/include/x86_64-linux-gnu/c++/7.2.0"
  cxx_builtin_include_directory: "/usr/include/c++/7.2.0/backward"
  cxx_builtin_include_directory: "/usr/include/clang/4.0.1/include"
  cxx_builtin_include_directory: "/usr/local/include"
  cxx_builtin_include_directory: "/usr/include/x86_64-linux-gnu"
  cxx_builtin_include_directory: "/usr/include"

ulfjack · 2018-02-16T16:38:05Z

$ ls -l /usr/include/clang/4.0.1/include
lrwxrwxrwx 1 root root 45 Okt  1 15:24 /usr/include/clang/4.0.1/include -> ../../../lib/llvm-4.0/lib/clang/4.0.1/include

ulfjack · 2018-02-16T16:48:18Z

$ clang-4.0 -E -xc++ - -v
...
 /usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0
 /usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/x86_64-linux-gnu/c++/7.2.0
 /usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/backward
 /usr/include/clang/4.0.1/include
 /usr/local/include
 /usr/include/x86_64-linux-gnu
 /usr/include
...

When I add -no-canonical-prefixes, I get an error.

clang-4.0: error: unable to execute command: Executable "clang-4.0" doesn't exist!

It looks like clang is broken.

ulfjack · 2018-02-16T17:01:19Z

Ok, the problem isn't that we're not specifying -no-canonical-prefixes. The problem is that the include paths for C and C++ are significantly different.

For C:

 /usr/local/include
 /usr/lib/llvm-4.0/bin/../lib/clang/4.0.1/include
 /usr/include/x86_64-linux-gnu
 /usr/include

For C++:

 /usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0
 /usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/x86_64-linux-gnu/c++/7.2.0
 /usr/bin/../lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/backward
 /usr/include/clang/4.0.1/include
 /usr/local/include
 /usr/include/x86_64-linux-gnu
 /usr/include

If I rename the file to .cc, then it works. We'll need to add c_builtin_include_directory, populate that, and then use the correct path in Bazel.

Previously this worked because the .c include path was a subset of the .cc include path. It still is, except that we can't tell because /usr/include/clang/4.0.1/include is a symlink to /usr/lib/llvm-4.0/lib/clang/4.0.1/include. As an alternative to tracking both C and C++ include paths, we could do a readlink -f on each entry and also add those to the list.

Option 2 seems a bit more hacky and might break again if we ever have the case where the .cc path is not a superset of the .c path. Option 1 seems more principled. We might also need to do this for objectivec.

Also, we might want to add a mechanism that allows a user to override the list of include paths on the command line, so that we at least have a workaround next time we run into this problem.

jmillikin-stripe · 2018-02-17T03:31:07Z

See also envoyproxy/envoy#2631 -- include paths are the same for C and C++, but different if -xc++ is set.

$ echo '' | clang-5.0 -E - -v 2>&1 | grep -A 5 'search starts here'
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/include
 /usr/lib/llvm-5.0/lib/clang/5.0.1/include
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.

$ echo '' | clang++-5.0 -E - -v 2>&1 | grep -A 5 'search starts here'
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/include
 /usr/lib/llvm-5.0/lib/clang/5.0.1/include
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.

$ echo '' | clang-5.0 -E -xc++ - -v 2>&1 | grep -A 5 'search starts here'
#include "..." search starts here:
#include <...> search starts here:
 /usr/bin/../lib/gcc/x86_64-linux-gnu/5.4.0/../../../../include/c++/5.4.0
 /usr/bin/../lib/gcc/x86_64-linux-gnu/5.4.0/../../../../include/x86_64-linux-gnu/c++/5.4.0
 /usr/bin/../lib/gcc/x86_64-linux-gnu/5.4.0/../../../../include/c++/5.4.0/backward
 /usr/include/clang/5.0.1/include
 /usr/local/include

ulfjack · 2018-02-17T23:12:53Z

Alternatively, we could add an option to disable the include check - if we're running the action in sandbox, it should be safe.

g-easy · 2018-04-13T05:35:58Z

This is still happening with bazel 0.12.0, e.g.:

cc_library(
    name = "main",
    srcs = ["main.c"],
)

Where main.c is just #include <stdint.h>

I get:

$ env CC=clang-4.0 bazel build :main
[...]
this rule is missing dependency declarations for the following files included by 'main.c':
  '/usr/lib/clang/4.0.1/include/stdint.h'
Target //:main failed to build

nicolasnoble · 2018-04-13T15:18:00Z

By the way, this is really affecting the grpc team directly, and preventing our ability to move away from building grpc using the Makefile and going to Bazel.

…

On Thu, Apr 12, 2018, 22:36 easy ***@***.***> wrote: This is still happening with bazel 0.12.0, e.g.: cc_library( name = "main", srcs = ["main.c"], ) Where main.c is just #include <stdint.h> I get: $ env CC=clang-4.0 bazel build :main [...] this rule is missing dependency declarations for the following files included by 'main.c': '/usr/lib/clang/4.0.1/include/stdint.h' Target //:main failed to build — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#3977 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AG8bprTLuzLNNwYPo-cy-KU8nQ2CU5P5ks5toDlSgaJpZM4QIkIf> .

ulfjack · 2018-04-25T12:21:09Z

Marking P1 based on feedback from grpc team. This is a really bad user experience for anyone on standard Ubuntu, which we claim to support.

Ping #3977 RELNOTES: None PiperOrigin-RevId: 194240625

hlopko · 2018-04-25T15:05:43Z

c122e47 fixed the issue for me, could you verify that it also fixes you cases? You'll have to build bazel@HEAD for this.

ulfjack · 2018-04-25T18:56:50Z

Works for me.

g-easy · 2018-05-14T08:57:19Z

#3977 (comment) is still happening with bazel 0.13.0, but not if it's a *.cc file. Maybe it's specific to C now? Please fix this for C sources also, e.g. grpc depends on zlib. :)

ulfjack · 2018-05-14T14:02:54Z

C and C++ is treated identically, so it's surprising if it works for one but not the other. Can you give us more context? What platform are you on? You may need to regenerate the C++ config, e.g., by setting CC=gcc.

g-easy · 2018-05-15T04:12:19Z

What platform are you on?

Linux.

You may need to regenerate the C++ config, e.g., by setting CC=gcc.

$ bazel clean --expunge
$ env CC=gcc bazel build :main
[succeeds]
$ env CC=clang bazel build :main
[...]
this rule is missing dependency declarations for the following files included by 'main.c':
  '/usr/lib/clang/4.0.1/include/stdint.h'
Target //:main failed to build

ulfjack · 2018-05-17T09:23:46Z

Unable to reproduce. What does your main.c file look like?

tommadams · 2018-05-17T21:03:38Z

Discovered this issue because I'm unable to build grpc with clang & bazel. I can repro g-easy's build errors on gLinux. This is blocking development of tensorflow/minigo.

Here's how I repro'd g-easy's example:

$ which clang
/usr/bin/clang

$ clang --version
clang version 4.0.1-10 (tags/RELEASE_401/final)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin

$ which bazel
/usr/local/bin/bazel

$ bazel version
Build label: 0.13.0
Build target: bazel-out/k8-opt/bin/src/main/java/com/google/devtools/build/lib/bazel/BazelServer_deploy.jar
Build time: Mon Oct 18 21:33:40 +50297 (1525078013620)
Build timestamp: 1525078013620
Build timestamp as int: 1525078013620

$ cat cc/bazel.c
#include <stdlib.h>
int main() { return 0; }

$ cat cc/BUILD
cc_binary(
    name = "bazel",
    srcs = ["bazel.c"],
)

# builds when not setting CC
$ bazel build cc:bazel
[succeeds]

# builds with CC=gcc
$ CC=gcc bazel build cc:bazel
[succeeds]

# does not build with CC=clang
$ CC=clang bazel build cc:bazel
INFO: Analysed target //cc:bazel (1 packages loaded).
INFO: Found 1 target...
ERROR: cc/BUILD:304:1: undeclared inclusion(s) in rule '//cc:bazel':
this rule is missing dependency declarations for the following files included by 'cc/bazel.c':
  '/usr/lib/clang/4.0.1/include/stddef.h'
Target //cc:bazel failed to build
Use --verbose_failures to see the command lines of failed build steps.
INFO: Elapsed time: 1.434s, Critical Path: 0.13s
INFO: 0 processes.
FAILED: Build did NOT complete successfully

For completeness, here are the errors I get trying to build grpc's examples:greeter_client:

$ bazel run examples:greeter_client
WARNING: /usr/local/google/home/tmadams/grpc/BUILD:1973:1: in srcs attribute of cc_library rule //:grpc_nanopb: please do not import '//third_party/nanopb:pb_common.c' directly. You should either move the file to this package or depend on an appropriate rule there. Since this rule was created by the macro 'grpc_generate_one_off_targets', the error might have been caused by the macro implementation in /usr/local/google/home/tmadams/grpc/bazel/grpc_build_system.bzl:172:12
WARNING: /usr/local/google/home/tmadams/grpc/BUILD:1973:1: in srcs attribute of cc_library rule //:grpc_nanopb: please do not import '//third_party/nanopb:pb_decode.c' directly. You should either move the file to this package or depend on an appropriate rule there. Since this rule was created by the macro 'grpc_generate_one_off_targets', the error might have been caused by the macro implementation in /usr/local/google/home/tmadams/grpc/bazel/grpc_build_system.bzl:172:12
WARNING: /usr/local/google/home/tmadams/grpc/BUILD:1973:1: in srcs attribute of cc_library rule //:grpc_nanopb: please do not import '//third_party/nanopb:pb_encode.c' directly. You should either move the file to this package or depend on an appropriate rule there. Since this rule was created by the macro 'grpc_generate_one_off_targets', the error might have been caused by the macro implementation in /usr/local/google/home/tmadams/grpc/bazel/grpc_build_system.bzl:172:12
INFO: Analysed target //examples:greeter_client (16 packages loaded).
INFO: Found 1 target...
ERROR: /usr/local/google/home/tmadams/.cache/bazel/_bazel_tmadams/4c83ceb29628e8749e4b91b77f6b4cd3/external/com_github_madler_zlib/BUILD.bazel:1:1: undeclared inclusion(s) in rule '@com_github_madler_zlib//:z':
this rule is missing dependency declarations for the following files included by 'external/com_github_madler_zlib/adler32.c':
  '/usr/lib/clang/4.0.1/include/stddef.h'
  '/usr/lib/clang/4.0.1/include/__stddef_max_align_t.h'
  '/usr/lib/clang/4.0.1/include/limits.h'
  '/usr/lib/clang/4.0.1/include/stdarg.h'
Target //examples:greeter_client failed to build
Use --verbose_failures to see the command lines of failed build steps.
INFO: Elapsed time: 12.545s, Critical Path: 0.30s
INFO: 3 processes: 2 linux-sandbox, 1 local.
FAILED: Build did NOT complete successfully
ERROR: Build failed. Not running target

g-easy · 2018-05-17T21:43:07Z

What does your main.c file look like?

A single line:

#include <stdint.h>

ulfjack · 2018-05-18T07:32:56Z

The fix unfortunately didn't make it into 0.13.0, but will be in 0.14.0 (you can see this in the GitHub UI when you click on the commit id c122e47 - it shows that it's in master, but it doesn't have any release tags). I tried @g-easy 's example with Bazel from HEAD, where it works for me.

tommadams · 2018-05-18T16:16:15Z

Ah, ok. Thanks!

soonho-tri · 2018-05-23T11:14:53Z

@ulfjack , is there a chance that c122e47 is included in the upcoming 0.13.1?

ulfjack · 2018-05-23T11:55:06Z

I believe we only cherrypick commits for regressions, not for bug fixes.

ulfjack · 2018-05-23T12:02:56Z

(That's a no.)

nicolasnoble · 2018-05-23T16:48:53Z

When is 0.14.0 scheduled then ?

g-easy · 2018-05-24T02:27:57Z

I can confirm my problem goes away with https://releases.bazel.build/0.14.0/rc2/index.html
Thanks!

lberki · 2018-05-24T07:41:16Z

0.14 is slated for early next week, according to @lfpino , the current release manager.

nicolasnoble · 2018-06-26T23:41:52Z

I believe that since 0.14 has been released, this issue can be closed now, right ?

katre assigned ulfjack Oct 31, 2017

katre added category: misc > bootstrap / installation P2 We'll consider working on this in future. (Assignee optional) type: bug labels Oct 31, 2017

ulfjack assigned hlopko and unassigned ulfjack Oct 31, 2017

jwnimmer-tri mentioned this issue Nov 11, 2017

Change Ubuntu default to clang-4.0 RobotLocomotion/drake#7459

Merged

jwnimmer-tri mentioned this issue Dec 15, 2017

Support clang-4.0 in CMake (+ MATLAB) builds RobotLocomotion/drake#7618

Closed

jamiesnape mentioned this issue Jan 10, 2018

Configure C and CXX compiler wrapper to compile project without using… RobotLocomotion/drake#7729

Merged

benjaminp mentioned this issue Feb 15, 2018

Inclusion checking is broken in 0.10.0 #4572

Closed

photex mentioned this issue Feb 16, 2018

Unable to build with bazel - Ubuntu 17.10 - Clang grpc/grpc#14454

Closed

jmillikin-stripe mentioned this issue Feb 19, 2018

Allow configuring different compilers for C and C++ #4644

Open

ulfjack added P1 I'll work on this now. (Assignee required) and removed P2 We'll consider working on this in future. (Assignee optional) labels Apr 25, 2018

bazel-io pushed a commit that referenced this issue Apr 25, 2018

Detect build-in include directories for C and C++, not only for C++

c122e47

Ping #3977 RELNOTES: None PiperOrigin-RevId: 194240625

judah mentioned this issue Apr 30, 2018

Missing dependency declarations for the following files included by X #4612

Closed

chenkan0104 mentioned this issue May 5, 2018

this rule is missing dependency declarations for the following files included by 'external/com_google_protobuf/src/google/protobuf/util/internal/json_escaping.cc' #5164

Closed

ulfjack added P2 We'll consider working on this in future. (Assignee optional) and removed P1 I'll work on this now. (Assignee required) labels May 18, 2018

ulfjack closed this as completed Jun 28, 2018

xor-gate mentioned this issue Nov 26, 2018

Bazel build fails: '@googletest//:gtest': this rule is missing dependency declarations google/googletest#1965

Closed

hlopko mentioned this issue Nov 28, 2018

Improve include directories support #6790

Closed

C++ code fails to build with clang 4.0 #3977

C++ code fails to build with clang 4.0 #3977

Comments

ulfjack commented Oct 27, 2017

ulfjack commented Oct 27, 2017

ulfjack commented Oct 27, 2017

benjaminp commented Oct 27, 2017

davido commented Oct 27, 2017 • edited Loading

nicolasnoble commented Feb 15, 2018

ulfjack commented Feb 15, 2018

nicolasnoble commented Feb 16, 2018

ulfjack commented Feb 16, 2018

ulfjack commented Feb 16, 2018

ulfjack commented Feb 16, 2018

hlopko commented Feb 16, 2018

ulfjack commented Feb 16, 2018

ulfjack commented Feb 16, 2018

ulfjack commented Feb 16, 2018

ulfjack commented Feb 16, 2018

ulfjack commented Feb 16, 2018

jmillikin-stripe commented Feb 17, 2018

ulfjack commented Feb 17, 2018

g-easy commented Apr 13, 2018

nicolasnoble commented Apr 13, 2018 via email

ulfjack commented Apr 25, 2018

hlopko commented Apr 25, 2018

ulfjack commented Apr 25, 2018

g-easy commented May 14, 2018

ulfjack commented May 14, 2018

g-easy commented May 15, 2018

ulfjack commented May 17, 2018

tommadams commented May 17, 2018

g-easy commented May 17, 2018

ulfjack commented May 18, 2018

tommadams commented May 18, 2018

soonho-tri commented May 23, 2018

ulfjack commented May 23, 2018

ulfjack commented May 23, 2018

nicolasnoble commented May 23, 2018

g-easy commented May 24, 2018

lberki commented May 24, 2018

nicolasnoble commented Jun 26, 2018

davido commented Oct 27, 2017 •

edited

Loading