Upgrade grpc to avoid gettid problems about agi HOT 9 CLOSED

Thanks @mattyclarkson, is this a blocking issue on your side? (just so that we can prioritize accordingly)

from agi.

I can't build AGI, so yes. I've tried upgrading on my side but stuck trying to resolve @upd and @build_bazel_rules_apple.

gRPC provides bazel/grpc_deps.bzl which finds all the necessary dependencies. Why do we not use that?

from agi.

OK, have worked around it by disabling the gettid delcaration. No rush.

We should upgrade the dependency though. I found it especially hard to upgrade as AGI dependencies don't seem to use the upstream project get_deps functions. It would make it much easier to upgrade if we changed to use those.

from agi.

Thanks for the pointers, looking into using bazel/grpc_deps.bzl now.

Bazel is a (very) fast-moving target, we probably don't use the get_deps because they were not available when we created our own bazel rules.

from agi.

Makes sense. Thanks for the updates.

It seems strange there isn't a standard Bazel function where you declare dependencies and it automatically resolves them. Most modern build systems support that now. Seems that most projects manually write a *_deps.bzl which seems a bit boilerplate-y

from agi.

@johnplate had a look and unfortunately, there seems to be breaking changes with newer version of GRPC.

We plan to upgrade, but later this year.

from agi.

Thank you @mattyclarkson for your report! I fully support your request to use at least gRPC 1.24 and grpc_deps.bzl. With our upcoming presentations at the GDC conference it would be too risky to change gRPC now, but I will take care of it soon after.

from agi.

No worries. It's easy to work around. The glibc gettid is guarded by #ifdef __USE_GNU so easy to avoid the build error.

from agi.

We've just merged #319 which will fix the linux build issues, however we're deferring updating gRPC since it has some implications we're not ready to address. Lowering the priority of this one since linux builds are unblocked now.

from agi.