Re: py-grpcio fails to build on NetBSD 11 and current

[Thomas Klausner <wiz%gatalith.at@localhost>]

On Fri, Aug 21, 2026 at 07:00:06AM +0100, Greg Troxel wrote:
> I first noticed on 2026Q2, and then I updated to the version you just
> committed thinking upstream may have fixed someting.
> 
> The relevant part of the log from NetBSD 11 (with mostly 2026Q2):
> 
> gcc -O2 -I/usr/pkg/include -I/usr/include -I/usr/pkg/include/python3.13 -I/usr/pkg/include -I/usr/include -I/usr/pkg/include/python3.13 -fPIC -I/usr/pkg/include/python3.13 -c /tmp/tmptw0z30_b/a.c -o tmp/tmptw0z30_b/a.o
> Traceback (most recent call last):
>   File "/usr/pkg/lib/python3.13/site-packages/setuptools/_distutils/spawn.py", line 83, in spawn
>     subprocess.check_call(cmd, env=_inject_macos_ver(env))
>     ~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>   File "/usr/pkg/lib/python3.13/subprocess.py", line 419, in check_call
>     raise CalledProcessError(retcode, cmd)
> subprocess.CalledProcessError: Command '['/tmp/work/net/py-grpcio/work/.cwrapper/bin/c++', '-O2', '-I/usr/pkg/include', '-I/usr/include', '-I/usr/pkg/include/python3.13', '-I/usr/pkg/include', '-I/usr/include', '-I/usr/pkg/include/python3.13', '-fPIC\
> ', '-D_WIN32_WINNT=1536', '-DGRPC_XDS_USER_AGENT_NAME_SUFFIX="Python"', '-DGRPC_XDS_USER_AGENT_VERSION_SUFFIX="1.83.0"', '-DOPENSSL_NO_ASM=1', '-DHAVE_CONFIG_H=1', '-DGRPC_ENABLE_FORK_SUPPORT=1', '-D__STDC_FORMAT_MACROS', '-Isrc/python/grpcio', '-Iin\
> clude', '-I.', '-I/usr/pkg/include', '-Ithird_party/address_sorting/include', '-I/usr/pkg/include', '-I/usr/pkg/include/re2', '-I/usr/pkg/include/openssl', '-Ithird_party/upb', '-Isrc/core/ext/upb-gen', '-Isrc/core/ext/upbdefs-gen', '-Ithird_party/ut\
> f8_range', '-Ithird_party/xxhash', '-I/usr/pkg/include', '-I/usr/pkg/include/python3.13', '-c', 'src/core/lib/event_engine/ares_resolver.cc', '-o', 'pyb/temp.netbsd-11.0-amd64-cpython-313/src/core/lib/event_engine/ares_resolver.o', '-pthread']' retur\
> ned non-zero exit status 1.
> 
> 
> 
> I don't understand  why _inject_macos_ver is running on NetBSD, or why
> this is ok on NetBSD 10.

I think you misunderstood the message. It fails in
subprocess.check_call(...) when calling c++.  There are probably some
compiler errors somewhere else that will tell what the real problem
is.

It built fine for me on -current yesterday.
 Thomas