I've arrived here because Home Assistant 2025.12 uses the python grpcio module. Thus I need to build it in a venv, rather than relying on a system package. There are a few things I'm not following, two small issues that I can file PRs for, and one issue that I'm unclear on. I'm using NetBSD 10 x86_64 with gcc 10 and python 3.13.
* No separate library and wrappers It looks like the python wrapper does not depend on a C/C++ libgrpc, but instead builds those files into the python module. That's not a complaint, but I think it would be good to note that in the README, as people may be expecting the "have a C lib, and then wrap it" idiom. * Can't find tags pypi has 1.76.0: https://pypi.org/project/grpcio/1.76.0/ and it has a download link https://files.pythonhosted.org/packages/b6/e0/318c1ce3ae5a17894d5791e87aea147587c9e702f24122cc7a5c8bbaeeb1/grpcio-1.76.0.tar.gz which all seemed normal. I needed to modify sources to build because of minor issues below, so "pip install" wasn't going to work. I found the repo at https://github.com/grpc/grpc but I see no releases and no tags. How do I find the bits that correspond to pypi 1.76.0? How was the tarball generated? * latent_see.cc uses abs() without std:: As I understand it, compilers can resolve bare abs() in various ways, including to the C99 standard library. The latent_see usage requires the more expansive types in C++'s std::abs() and thus it should be written that way. PR to follow; just mentioning it. * lack of --std=c++17 The codebase needs c++17, but doesn't in general add --std=c++17 to build lines. This causes failure with gcc 10, which doesn't default to c++17 but supports it with --std=c++17. I have a patch to add a netbsd stanza that adds --std; that's the minimal change. PR to follow. Alternatively, someone could add code that says "add --std=c++17 always", or maybe if !windows, an that would resolve the issue on all platforms, but that's much harder to test and I don't want to jump in with that as an outsider. * conflicts with installed protobuf pkgsrc has protobuf 33.1, which according to https://github.com/protocolbuffers/protobuf is the current release. Headers are installed in /usr/pkg/include. Building grpc python (with python313 setup.py build), I find (with interpolated -I flags probably from python-config) that the build reads the package upb defs.inc instead of the one in third_party. The versions are different and there's trouble in TSAN macros -- but removing the package makes the build succeed. Clearly gprc-included upb code and package upb headers don't go together. It looks like the included version is upb 31.0, from the git logs. I don't see a way to use system upb. I don't see a plan to avoid upb headers that are at the same prefix as python, yet this seems likely necessary for many. Do others run into this? * status With the 2 patches above and the workaround of removing pkg protobuf, the build completes. On to running tests, but that's promising. Thanks, Greg -- You received this message because you are subscribed to the Google Groups "grpc.io" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/d/msgid/grpc-io/rmiy0nhhjur.fsf%40s1.lexort.com.
