grpc: installations of grpcio 1.47 && 1.50 fails with gcc errors

What version of gRPC and what language are you using?

1.47 (but 1.50 inhibits the same issue)

What operating system (Linux, Windows,…) and version?

Macos (Ventura 13.0.1)

What runtime / compiler are you using (e.g. python version or version of gcc)

3.11.0

Apple clang version 14.0.0 (clang-1400.0.29.202)
Target: arm64-apple-darwin22.1.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin

What did you do?

Please provide either 1) A unit test for reproducing the bug or 2) Specific steps for us to follow to reproduce the bug. If there’s not enough information to debug the problem, gRPC team may close the issue at their discretion. You’re welcome to re-open the issue once you have a reproduction.

What did you expect to see?

What did you see instead?

https://gist.github.com/georgettica/80cc8d8197d02bcbbefa4bd084d12cfe

Make sure you include information that can help us debug (full error message, exception listing, stack trace, logs).

See TROUBLESHOOTING.md for how to diagnose problems better.

Anything else we should know about your project / environment?

PATH =

/opt/homebrew/bin
/opt/homebrew/sbin
/opt/homebrew/opt/python@3.11/bin
/opt/homebrew/opt/openssl@3/bin
/opt/homebrew/opt/make/libexec/gnubin
/opt/homebrew/opt/llvm@15/bin
/opt/homebrew/opt/coreutils/libexec/gnubin
/opt/homebrew/Cellar/gcc/12.2.0/bin/
/opt/homebrew/opt/ansible@2.9/bin
/opt/homebrew/bin
/usr/local/bin
/System/Cryptexes/App/usr/bin
/usr/bin
/bin
/usr/sbin
/sbin
/Library/Apple/usr/bin

CPPFLAGS =

-I /opt/homebrew/opt/llvm@15/include 
-I /opt/homebrew/opt/openssl@3/include 
-I /opt/homebrew/Cellar/python@3.11/3.11.0/Frameworks/Python.framework/Versions/3.11/include/python3.11/

About this issue

Original URL
State: closed
Created 2 years ago
Comments: 16 (5 by maintainers)

Most upvoted comments

Based on your updated log, those defines really did resolve the issue I pointed out above. There’s just another issue going on with your build. You’ve got some symbol clashing going on between your system-installed openssl and the vendored boringssl packaged with gRPC:

      third_party/boringssl-with-bazel/src/include/openssl/base.h:333:29: error: typedef redefinition with different types ('struct asn1_null_st' vs 'int')
      typedef struct asn1_null_st ASN1_NULL;
                                  ^
      /opt/homebrew/opt/openssl@3/include/openssl/types.h:62:13: note: previous definition is here
      typedef int ASN1_NULL;

To resolve this, either remove openssl from your include path to use boringssl or set GRPC_PYTHON_BUILD_SYSTEM_OPENSSL=True to use openssl.

gnossen on Dec 1, 2022

@georgettica Actually, that’s my fault. Github truncated the view. It’s all present in the raw view. Sorry about that.

      clang -Wsign-compare -Wunreachable-code -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX13.sdk -I /opt/homebrew/opt/llvm@15/include -I /opt/homebrew/opt/openssl@3/include -I /opt/homebrew/Cellar/python@3.11/3.11.0/Frameworks/Python.framework/Versions/3.11/include/python3.11/ -I /opt/homebrew/opt/llvm@15/include -I /opt/homebrew/opt/openssl@3/include -I /opt/homebrew/Cellar/python@3.11/3.11.0/Frameworks/Python.framework/Versions/3.11/include/python3.11/ -D_WIN32_WINNT=1536 -DGRPC_XDS_USER_AGENT_NAME_SUFFIX=\"Python\" -DGRPC_XDS_USER_AGENT_VERSION_SUFFIX=\"1.47.0\" -DOPENSSL_NO_ASM=1 -DGPR_BACKWARDS_COMPATIBILITY_MODE=1 -DHAVE_CONFIG_H=1 -DGRPC_ENABLE_FORK_SUPPORT=1 "-DPyMODINIT_FUNC=extern \"C\" __attribute__((visibility (\"default\"))) PyObject*" -DGRPC_POSIX_FORK_ALLOW_PTHREAD_ATFORK=1 -Isrc/python/grpcio -Iinclude -I. -Ithird_party/abseil-cpp -Ithird_party/address_sorting/include -Ithird_party/cares/cares/include -Ithird_party/cares -Ithird_party/cares/cares -Ithird_party/cares/config_darwin -Ithird_party/re2 -Ithird_party/boringssl-with-bazel/src/include -Ithird_party/upb -Isrc/core/ext/upb-generated -Isrc/core/ext/upbdefs-generated -Ithird_party/xxhash -Ithird_party/zlib -I/privateDIR/.venv/include -I/opt/homebrew/opt/python@3.11/Frameworks/Python.framework/Versions/3.11/include/python3.11 -c third_party/abseil-cpp/absl/synchronization/internal/waiter.cc -o python_build/temp.macosx-13-arm64-cpython-311/third_party/abseil-cpp/absl/synchronization/internal/waiter.o -std=c++14 -stdlib=libc++ -fvisibility=hidden -fno-wrapv -fno-exceptions -DHAVE_UNISTD_H -pthread
      src/python/grpcio/grpc/_cython/cygrpc.cpp:126592:23: error: no member named 'exc_type' in '_err_stackitem'
          while ((exc_info->exc_type == NULL || exc_info->exc_type == Py_None) &&

This looks like it’s related to these issues:

So the core CPython team made a breaking C API change in 3.11.0a4 to how exceptions are represented, which was not then updated in the calling code in Cython. The Cython team did make a fix, but only on the still experimental 3.X branch.

What’s odd here is that if that were the whole picture, I would not expect our 3.11 builds to be working properly, which they are. We’re currently building against 3.11.0rc1 which, to my knowledge, has no C API changes from the final 3.11.0 release. @georgettica Can you please confirm the exact version of Python 3.11 that you’re using? Also, as a workaround, I think you might be able to work around by setting the environment variable GRPC_PYTHON_CFLAGS="-DCYTHON_FAST_THREAD_STATE=0 -DCYTHON_USE_EXC_INFO_STACK=0" based on this comment.

gnossen on Nov 29, 2022