grpc: need to update to latest version |
|||||||
Issue descriptionthe latest llvm-compiler find out that create_channel.cc has an unused variable. See this change that fixes the warning. https://critique.corp.google.com/#review/172320899/depot/google3/third_party/grpc/src/cpp/client/create_channel.cc. however, this actually points to a bug. "init_lib" should be of type GrpcLibraryCodegen. This can be seen in the latest version of this file in: https://cs.corp.google.com/piper///depot/google3/third_party/grpc/src/cpp/client/create_channel.cc?q=create_channel.cc For now, I am just dealing with the warning (removing the unused variable). I will let chirantan update the package.
,
Nov 1 2017
,
Nov 1 2017
not really blocking 778316 since we have a workaround. But using this mechanism to keep track of what needs to be fixed.
,
Dec 26 2017
,
Jan 2 2018
[It appears that a bunch of old cros issues bulk-added the "Infra" component recently, but they should probably be "Infra>Client>ChromeOS".]
,
Feb 5 2018
,
Nov 30
Chirantan, are you aware of any plans for doing this change? Or do you maybe have an idea of how complex would the update be (for example, from perspective of gRPC's dependencies, or our local patches)? The context for the question is bug 910079 (even though, to be clear, we don't know yet whether upreving gRPC would actually fix that).
,
Dec 1
allenwebb@ has a CL out to update grpc to 1.16.1: https://chromium-review.googlesource.com/c/chromiumos/overlays/chromiumos-overlay/+/1336735 The 2 big issues with updating grpc are porting our patches and making sure it cross-compiles cleanly. For the patches, only our vsock patch is required as it is now used by several different projects. Last time I checked the patch couldn't be applied directly because upstream changed a bunch of files from .c to .cc. However, the content of the patch seemed like it would apply cleanly. The more tricky part is making sure that it cross-compiles cleanly. Unfortunately upstream decided to add cross-compilation support despite not being able to actually test it. This sadly makes it harder to cross-compile because the build makes weird assumptions (like pkg-config cannot be used during cross-compiling) and just does some stuff wrong (using the same CFLAGS for both the build arch and the target arch). I cannot say how much effort it would take to fix the problems because I don't really know what's broken. I see now that upstream does support cmake so it might actually be easier to fix the cross-compilation issues by using cmake (instead of their terribly hacked makefile) because we know how to set that up to Do The Right Thing (via the cmake-utils eclass).
,
Dec 1
Another option is to use bazel but I'm not sure how well supported that is in our sdk.
,
Dec 1
Can we file an upstream bug for grpc to fix cross compilation? If they added support, they should ensure it works. Bazel needs Java (AFAIK).
,
Dec 1
There are many upstream bugs about cross-compilation. https://github.com/grpc/grpc/search?q=cross+compile&type=Issues shows 114 issues. As for bazel, all I meant was that we already have it in the SDK for building tensorflow so if the support is mature enough we can look at using it for grpc as well.
,
Dec 1
You can see the discussion in the pull request I opened in July 2017: https://github.com/grpc/grpc/pull/11476#issuecomment-309087216 Basically, upstream's attitude seems to be "cross-compilation is a lot of work to support so we cannot commit to it beyond best-effort". However, their best-effort is actively making things worse and it would actually be easier for us if they didn't support it at all.
,
Dec 28
Now that the newer portage has landed (fixing recompiling when slots change for protobuf) I am taking another look at this. |
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by llozano@chromium.org
, Nov 1 2017