search

pubref / rules_protobuf

Bazel rules for building protocol buffers and gRPC services (java, c++, go, ...)
Other
231 stars 157 forks source link

Unable to build `cc_proto_library` with GRPC support on Ubuntu #7

Closed nelhage closed 8 years ago

nelhage commented 8 years ago

If I try to build a simple cc_proto_library with GRPC support (I'm copy-pasting the example from bzl/cpp/README.md, the build fails because the com_github_grpc_grpc build fails:

[nelhage@monomorphique:~/code/grpc-test]$ bazel build :protolib
INFO: Found 1 target...
ERROR: /home/nelhage/.cache/bazel/_bazel_nelhage/809c45c005e5377cc317259ef3196039/external/com_github_grpc_grpc/BUILD:159:1: C++ compilation of rule '@com_github_grpc_grpc//:grpc' failed: linux-sandbox failed: error executing command /home/nelhage/.cache/bazel/_bazel_nelhage/809c45c005e5377cc317259ef3196039/execroot/grpc-test/_bin/linux-sandbox ... (remaining 61 argument(s) skipped).
In file included from external/com_github_grpc_grpc/src/core/ext/lb_policy/grpclb/proto/grpc/lb/v1/load_balancer.pb.c:36:0:
external/com_github_grpc_grpc/src/core/ext/lb_policy/grpclb/proto/grpc/lb/v1/load_balancer.pb.h:38:35: fatal error: third_party/nanopb/pb.h: No such file or directory
compilation terminated.
Target //:protolib failed to build
Use --verbose_failures to see the command lines of failed build steps.
INFO: Elapsed time: 32.042s, Critical Path: 8.64s

I believe this is a symptom of https://github.com/grpc/grpc/issues/6728 but is there some workaround that allows this repository to work? I could vendor nanopb into my own third_party directory, but (a) that's fairly dissatisfying and (b) I'm not clear I won't run into other failures.

pcj commented 8 years ago

I'll start investigating this in docker. What's your environment?

nelhage commented 8 years ago

Linux, Ubuntu 14.04 Xenial, running bazel 0.3.1 from the official apt repository

nelhage commented 8 years ago

Sorry, I think https://github.com/grpc/grpc/issues/6083 may be the more relevant issue, but in either case the query of whether there's a minimally-invasive workaround stands. Thanks for looking into it!

pcj commented 8 years ago

Currently compiles fine on debian/jessie but failing as you report on Ubuntu Xenial 16.04 and Trusty 14.04 on GCE. Current (unsatisfactory) workaround is to use debian.

However, the travis-ci "mega" image that tests this repo is based on Ubuntu 14.04 with what seems like pretty standard gcc-4.8 install via update-alternatives from https://github.com/travis-ci/travis-cookbooks/tree/3e0e60d2e996563223fceb2e9ad98f2c68b33b43/cookbooks/gcc.

Maybe @nicolasnoble or @yang-g has insight on this, or perhaps https://github.com/grpc/grpc/pull/6851 will fix?

nelhage commented 8 years ago

That's fascinating and pretty confusing, and suggests gcc-4.8 vs. 5.x as the possible culprit, although I'm struggling to figure out how that could affect this. But it does give me something to dig into. I'll report back if I uncover anything.

nelhage commented 8 years ago

Ah-ha, I think I figure it out. It's a sandbox thing. The build will work if the sandbox is disabled (which it is in travis), and I'm guessing your jessie doesn't support the sandbox for some reason.

The grpc checkout includes third_party/nanopb, so the files are available from that path, but because //external:nanopb is bound elsewhere, there isn't a declared dependency there. So with sandbox enforcing, bazel doesn't bring those files into the sandbox, and the compiler can't find it. With the sandbox disabled, the compiler picks them up even though they're undeclared.

That at least gives me a workaround for the moment. I'm hopeful that grpc/grpc#6851 will fix properly.

pcj commented 8 years ago

Nice pickup about the sandbox! I've added a note on the README.md about this. Will keep this issue open for now.