-
Notifications
You must be signed in to change notification settings - Fork 4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
C++ code fails to build with clang 4.0 #3977
Comments
Failing command line:
It works with clang-3.9:
|
The -c and --copt parameters are not relevant. Same behavior without them. |
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 |
FYI: Bazel cannot be built on GCC 7 too: #3903. |
Is there any bug entered in the Debian bug system about that if we believe this is on them? |
Good point. I don't think we have. |
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. |
It might be due to the bugfix for https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=855222 |
Note that I haven't double-checked @benjaminp's statement, but he's usually right about these things. |
Marcel has a possible fix at https://bazel-review.googlesource.com/c/bazel/+/39872. |
Hmm cannot repro. |
I still get errors with that patch
|
Here's a snippet from the CROSSTOOL file:
|
|
When I add -no-canonical-prefixes, I get an error.
It looks like clang is broken. |
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:
For C++:
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. |
See also envoyproxy/envoy#2631 -- include paths are the same for C and C++, but different if
|
Alternatively, we could add an option to disable the include check - if we're running the action in sandbox, it should be safe. |
This is still happening with bazel 0.12.0, e.g.:
Where main.c is just I get:
|
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>
.
|
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
c122e47 fixed the issue for me, could you verify that it also fixes you cases? You'll have to build bazel@HEAD for this. |
Works for me. |
#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. :) |
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. |
Linux.
$ 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 |
Unable to reproduce. What does your main.c file look like? |
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:
For completeness, here are the errors I get trying to build grpc's examples:greeter_client:
|
A single line:
|
Ah, ok. Thanks! |
I believe we only cherrypick commits for regressions, not for bug fixes. |
(That's a no.) |
When is 0.14.0 scheduled then ? |
I can confirm my problem goes away with https://releases.bazel.build/0.14.0/rc2/index.html |
0.14 is slated for early next week, according to @lfpino , the current release manager. |
I believe that since 0.14 has been released, this issue can be closed now, right ? |
On a Ubuntu 17.04 machine, with clang-4.0 installed, I get this error from Bazel for some straightforward C++ code:
The text was updated successfully, but these errors were encountered: