py-grpcio fails to build if an external abseil is installed via some other mechanism on the user's machine, eg pypi.

[mouse07410 (Mouse)]

MacOS 11.5.1, Xcode-12.5.1. Same failure with py38-grpcio 1.39.

$ port outdated
The following installed ports are outdated:
py38-grpcio                    1.38.1_0 < 1.39.0_0       
py39-grpcio                    1.38.1_0 < 1.39.0_0       
$ sudo port upgrade py39-grpcio
--->  Computing dependencies for py39-grpcio
--->  Fetching archive for py39-grpcio
--->  Attempting to fetch py39-grpcio-1.39.0_0.darwin_20.x86_64.tbz2 from https://packages.macports.org/py39-grpcio
--->  Attempting to fetch py39-grpcio-1.39.0_0.darwin_20.x86_64.tbz2 from https://nue.de.packages.macports.org/py39-grpcio
--->  Attempting to fetch py39-grpcio-1.39.0_0.darwin_20.x86_64.tbz2 from http://atl.us.packages.macports.org/py39-grpcio
--->  Fetching distfiles for py39-grpcio
--->  Verifying checksums for py39-grpcio
--->  Extracting py39-grpcio
--->  Configuring py39-grpcio
--->  Building py39-grpcio                               
Error: Failed to build py39-grpcio: command execution failed
Error: See /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_grpc/py39-grpcio/main.log for details.
Error: Follow https://guide.macports.org/#project.tickets if you believe there is a bug.

Before, it failed only when one built py39-tensorflow +native. Now, even without +native the build fails. Another question is why the port doesn't pull the pre-built binaries from the build-bot.

Log attached.

[reneeotten (Renee Otten)]

is this related to any of the other ​reports?

[mouse07410 (Mouse)]

is this related to any of the other ​reports?

I don't know, but I don't think so. Here are my flags:

$ env | grep FLAG
CXXFLAGS=-std=gnu++17 -O3 -march=native -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk
OPENSSL_CFLAGS= -I/opt/local/include
CFLAGS=-O3 -std=gnu18 -march=native -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk

Here are some of the error messages:

.  .  .  .  .
:info:build /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_
ports_devel_grpc/py39-grpcio/work/compwrap/cc/usr/bin/clang -Wno-unused-result -Wsign-compare -Wunreachable-co
de -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -pipe -Os -isysroot/Library/Developer/CommandLineTools/S
DKs/MacOSX11.sdk -arch x86_64 -isysroot/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/De
veloper/SDKs/MacOSX11.3.sdk -D_WIN32_WINNT=1536 -DGRPC_XDS_USER_AGENT_NAME_SUFFIX="Python" -DGRPC_XDS_USER_AGE
NT_VERSION_SUFFIX="1.39.0" -DOPENSSL_NO_ASM=1 -DGPR_BACKWARDS_COMPATIBILITY_MODE=1 -DHAVE_CONFIG_H=1 -DGRPC_EN
ABLE_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 -I/opt/local/include -I/opt/local/include/re2 -I/opt/local/include/openssl -Ithird_party/upb -
Isrc/core/ext/upb-generated -Isrc/core/ext/upbdefs-generated -Ithird_party/xxhash -I/opt/local/include -I/opt/
local/Library/Frameworks/Python.framework/Versions/3.9/include/python3.9 -c src/core/ext/upb-generated/envoy/c
onfig/route/v3/scoped_route.upb.c -o python_build/temp.macosx-11.0-x86_64-3.9/src/core/ext/upb-generated/envoy
/config/route/v3/scoped_route.upb.o -stdlib=libc++ -fvisibility=hidden -fno-wrapv -fno-exceptions -DHAVE_UNIST
D_H -pthread
:info:build In file included from src/core/ext/filters/client_channel/lb_policy/weighted_target/weighted_targe
t.cc:24:
:info:build In file included from /opt/local/include/absl/strings/str_cat.h:62:
:info:build In file included from /opt/local/include/absl/strings/numbers.h:37:
:info:build In file included from /opt/local/include/absl/numeric/int128.h:698:
:info:build third_party/abseil-cpp/absl/numeric/int128_have_intrinsic.inc:37:8: error: unknown type name 'int128'; did you mean 'uint128'?
:info:build inline int128& int128::operator=(__int128 v) {
:info:build        ^~~~~~
:info:build        uint128
:info:build /opt/local/include/absl/numeric/int128.h:91:9: note: 'uint128' declared here
:info:build         uint128 {
:info:build         ^
:info:build In file included from src/core/ext/filters/client_channel/resolver/dns/c_ares/dns_resolver_ares.cc:28:
:info:build In file included from /opt/local/include/absl/strings/str_cat.h:62:
:info:build In file included from /opt/local/include/absl/strings/numbers.h:37:
:info:build In file included from /opt/local/include/absl/numeric/int128.h:698:
:info:build third_party/abseil-cpp/absl/numeric/int128_have_intrinsic.inc:37:8: error: unknown type name 'int128'; did you mean 'uint128'?
.  .  .  .  .

[kencu (Ken)]

your log has so many errors (hundreds) that it is hard to know where to begin.

Let's start with this basic one:

:info:build Compiling with an SDK that doesn't seem to exist: /Library/Developer/CommandLineTools/SDKs/MacOSX11.sdk
:info:build Please check your Xcode installation

What SDK are we attempting to build against? Does it actually exist on your system?

[kencu (Ken)]

and after that, perhaps for a whole new area of trying to sort things out, can you show us what this file looks like?:

cat work/compwrap/cc/usr/bin/clang

[mouse07410 (Mouse)]

your log has so many errors (hundreds) that it is hard to know where to begin.

The ones I showed above are the first, so might as well begin from/with them.

Let's start with this basic one... What SDK are we attempting to build against? Does it actually exist on your system?

$ xcrun --show-sdk-path
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk
$ xcrun --show-sdk-platform-version
11.3
$ xcrun --show-sdk-platform-path
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform
$ xcrun --show-sdk-platform-version
11.3
$ clang -v
Apple clang version 12.0.5 (clang-1205.0.22.11)
Target: x86_64-apple-darwin20.6.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
$ ll -d /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/
drwxr-xr-x  5 ur20980  MITLL\Domain Users  160 Jun 22 20:53 /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs//
$ ll /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/
total 0
drwxr-xr-x  5 ur20980  MITLL\Domain Users  160 Jun 22 20:53 ./
drwxr-xr-x  6 ur20980  MITLL\Domain Users  192 Jun  8 20:37 ../
drwxr-xr-x  5 ur20980  MITLL\Domain Users  160 Mar 16 10:03 DriverKit20.4.sdk/
drwxr-xr-x  7 ur20980  MITLL\Domain Users  224 Mar 16 10:03 MacOSX.sdk/
lrwxr-xr-x  1 ur20980  MITLL\Domain Users   10 Jun 22 20:51 MacOSX11.3.sdk@ -> MacOSX.sdk
$ 

and after that, perhaps for a whole new area of trying to sort things out, can you show us what this file looks like?: cat work/compwrap/cc/usr/bin/clang

It would be easier if you told me where I should look for the relative directory work/compwrap/.....:

$ cat /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_grpc/py39-grpcio/work/compwrap/cc/usr/bin/clang
#!/bin/bash
exec /usr/bin/clang   -Os -I/opt/local/include -isysroot/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.3.sdk -pipe ${MACPORTS_LEGACY_SUPPORT_CPPFLAGS}  "${@}" 
$ cat /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_grpc/py39-grpcio/work/compwrap/cxx/usr/bin/clang++ 
#!/bin/bash
exec /usr/bin/clang++   -Os -DNDEBUG -I/opt/local/include -stdlib=libc++ -isysroot/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.3.sdk -pipe ${MACPORTS_LEGACY_SUPPORT_CPPFLAGS}  "${@}" 
$ 

Note: I've seen that the invocation (erroneously) requests MacOS11.3.sdk instead of MacOS11.sdk, it appears to fail to resolve symlinks and find some header files. So, it may be that the given -isysroot is killing the build, I'm not sure. That would be an Apple bug, but it's easier/quicker for Macports to work around it, than to wait for Apple to get off their tail and fix it.

[kencu (Ken)]

well, I figured this many years in, you knew where the work directory was :)

the rest of this is pretty ugly to debug this way.

[mouse07410 (Mouse)]

well, I figured this many years in, you knew where the work directory was :)

Well, I do know what my SDKs are and where they reside, but one reason for using Macports for me is that I don't have to become an expert in it - normally it "just works". So, I haven't familiarized myself with the "bowels" of the package creation and build process - thankfully there are experts to take care of that and relieve me to do what I'm good at. ;-)

the rest of this is pretty ugly to debug this way

It sure is.

As a shot in the dark: is there a simple way to replace isysroot that Macports decided for this package with what my xcrun --show-sdk-path returns? As a test? If it can be done via simple editing of Portfile and you can remind me how to do that - I'll be happy to try (especially since this package is much quicker to build than gcc11 or clang-12 ;).

[kencu (Ken)]

We haven't heard yet if you have the SDK that MacPorts appears to be actually trying to use:

/Library/Developer/CommandLineTools/SDKs/MacOSX11.sdk

[mouse07410 (Mouse)]

We haven't heard yet if you have the SDK that MacPorts appears to be actually trying to use /Library/Developer/CommandLineTools/SDKs/MacOSX11.sdk

No, of course not. CLT has a bug that prevents Haskell GHC from working correctly, so none of my machines has it.

Why is Macports trying to use CLT, when the work/compwrap/cc/usr/bin/clang clearly (and almost correctly!) points at the Xcode.app? See

$ cat /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_grpc/py39-grpcio/work/compwrap/cc/usr/bin/clang
#!/bin/bash
exec /usr/bin/clang   -Os -I/opt/local/include -isysroot/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.3.sdk -pipe ${MACPORTS_LEGACY_SUPPORT_CPPFLAGS}  "${@}" 

In any case, (a) the build seems to proceed to 100% mark (as indicated by the port progress bar), and then fails, (b) there's about 900 ports on one machine and 1070 ports on another one - they all seem to build fine (yeah, some are pulled as binaries, but enough get rebuilt from sources to validate my setup in general).

[kencu (Ken)]

OK, progress -- so you have a nonstandard setup and you are missing the sdk that MacPorts is trying to use. No surprise it fails.

So let's try the simple step of building it with the sdk it is asking for back in the usual default location. A symlink will do nicely.

[mouse07410 (Mouse)]

OK, progress -- so you have a nonstandard setup and you are missing the sdk that MacPorts is trying to use. No surprise it fails.

Any reason why other ports do not fail? E.g.,

$ sudo port install -s py38-scipy
--->  Computing dependencies for py38-scipy
The following dependencies will be installed: 
 py38-beniget
 py38-decorator
 py38-networkx
 py38-ply
 py38-pytest-runner
 py38-pythran
Continue? [Y/n]: y
--->  Fetching distfiles for py38-beniget
--->  Attempting to fetch beniget-0.4.1.tar.gz from https://files.pythonhosted.org/packages/source/b/beniget
--->  Verifying checksums for py38-beniget
--->  Extracting py38-beniget
--->  Configuring py38-beniget
--->  Building py38-beniget
--->  Staging py38-beniget into destroot
--->  Installing py38-beniget @0.4.1_0                   
--->  Activating py38-beniget @0.4.1_0
--->  Cleaning py38-beniget
--->  Fetching distfiles for py38-decorator
--->  Attempting to fetch decorator-5.0.9.tar.gz from https://files.pythonhosted.org/packages/source/d/decorator
--->  Verifying checksums for py38-decorator
--->  Extracting py38-decorator
--->  Configuring py38-decorator
--->  Building py38-decorator
--->  Staging py38-decorator into destroot
--->  Installing py38-decorator @5.0.9_0                 
--->  Activating py38-decorator @5.0.9_0
--->  Cleaning py38-decorator
--->  Fetching distfiles for py38-networkx
--->  Attempting to fetch networkx-2.6.2.tar.gz from https://files.pythonhosted.org/packages/source/n/networkx
--->  Verifying checksums for py38-networkx
--->  Extracting py38-networkx
--->  Configuring py38-networkx
--->  Building py38-networkx
--->  Staging py38-networkx into destroot
--->  Installing py38-networkx @2.6.2_0                  
--->  Activating py38-networkx @2.6.2_0
--->  Cleaning py38-networkx
--->  Fetching distfiles for py38-ply
--->  Attempting to fetch ply-3.11.tar.gz from https://www.dabeaz.com/ply/
--->  Verifying checksums for py38-ply
--->  Extracting py38-ply
--->  Configuring py38-ply
--->  Building py38-ply
--->  Staging py38-ply into destroot
--->  Installing py38-ply @3.11_0                        
--->  Activating py38-ply @3.11_0
--->  Cleaning py38-ply
--->  Fetching distfiles for py38-pytest-runner
--->  Attempting to fetch pytest-runner-5.3.1.tar.gz from https://files.pythonhosted.org/packages/source/p/pytest-runner
--->  Verifying checksums for py38-pytest-runner
--->  Extracting py38-pytest-runner
--->  Configuring py38-pytest-runner
--->  Building py38-pytest-runner
--->  Staging py38-pytest-runner into destroot           
--->  Installing py38-pytest-runner @5.3.1_0             
--->  Activating py38-pytest-runner @5.3.1_0
--->  Cleaning py38-pytest-runner
--->  Fetching distfiles for py38-pythran
--->  Attempting to fetch pythran-0.9.12.post1.tar.gz from https://files.pythonhosted.org/packages/source/p/pythran
--->  Verifying checksums for py38-pythran
--->  Extracting py38-pythran
--->  Configuring py38-pythran
--->  Building py38-pythran
--->  Staging py38-pythran into destroot                 
--->  Installing py38-pythran @0.9.12.post1_0            
--->  Activating py38-pythran @0.9.12.post1_0
--->  Cleaning py38-pythran
--->  Fetching distfiles for py38-scipy
--->  Attempting to fetch scipy-1.7.1.tar.gz from https://github.com/scipy/scipy/tarball/v1.7.1
--->  Verifying checksums for py38-scipy                                                     
--->  Extracting py38-scipy
--->  Applying patches to py38-scipy
--->  Configuring py38-scipy
--->  Building py38-scipy
--->  Staging py38-scipy into destroot                   
--->  Installing py38-scipy @1.7.1_0+gfortran+openblas   
--->  Activating py38-scipy @1.7.1_0+gfortran+openblas
--->  Cleaning py38-scipy
--->  Updating database of binaries
--->  Scanning binaries for linking errors
--->  No broken files found.                             
--->  No broken ports found.
$ 

[kencu (Ken)]

just lucky, I guess.

And we still don't know if putting the sdk back will fix you. It's just "step 1".

[mouse07410 (Mouse)]

just lucky, I guess.

So, when out of more than 1000 ports, about 990 build fine - you guess it's "just luck"?

Note that info:build Compiling with an SDK that doesn't seem to exist: /Library/Developer/CommandLineTools/SDKs/MacOSX11.sdk is merely an info message - not an error. The actual compiler invocation proves that Macports does find the (mostly) correct SDK:

info:build /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_grpc/py39-grpcio/work/compwrap/cc/usr/bin/clang -Wno-unused-result <some stuff> -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX11.sdk -arch x86_64 -isysroot/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.3.sdk -D_WIN32_WINNT=1536 -DGRPC_XDS_USER_AGENT_NAME_SUFFIX="Python" <some more stuff> -Isrc/python/grpcio -Iinclude -I. -Ithird_party/abseil-cpp -Ithird_party/address_sorting/include -I/opt/local/include -I/opt/local/include/re2 -I/opt/local/include/openssl -Ithird_party/upb -Isrc/core/ext/upb-generated -Isrc/core/ext/upbdefs-generated -Ithird_party/xxhash -I/opt/local/include -I/opt/local/Library/Frameworks/Python.framework/Versions/3.9/include/python3.9 -c third_party/upb/upb/table.c -o python_build/temp.macosx-11.0-x86_64-3.9/third_party/upb/upb/table.o -stdlib=libc++ -fvisibility=hidden -fno-wrapv -fno-exceptions -DHAVE_UNISTD_H -pthread

Observe two -isysroot flags, one with wrong/nonexistent path, the other one pointing to a symlink to the right SDK.

And we still don't know if putting the sdk back will fix you.

I'm 99.999% sure it won't/can't.

Considering that /Library/Developer/CommandLineTools contains plenty of stuff, not just the SDK itself - I'm very much leery of (no offense meant!) "vivisecting" the SDK, as the likelihood of breaking other stuff in a more serious way because the rest of the CLT is not there is pretty high.

It's just "step 1".

Let's proceed to "step 2". ;-)

"First lesson is $10, all subsequent ones cost $5. - Let's start with lesson 2?" ;-)

[kencu (Ken)]

I won't help you any further until you do step 1.

No time to waste.

Perhaps someone else might feel interested, though!

[mouse07410 (Mouse)]

As problem is the same and manifests the same way, it doesn't matter which of the two ports (py38-grpcio or py39-grpcio) we're talking about.

$ sudo mkdir -p /Library/Developer/CommandLineTools/SDKs
$ sudo ln -s /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk /Library/Developer/CommandLineTools/SDKs/MacOSX11.sdk
$ ll /Library/Developer/CommandLineTools/SDKs/
total 0
drwxr-xr-x  3 root  admin  96 Aug 11 15:08 ./
drwxr-xr-x  3 root  admin  96 Aug 11 15:06 ../
lrwxr-xr-x  1 root  admin  94 Aug 11 15:08 MacOSX11.sdk@ -> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk
$ sudo port install -sfn py38-grpcio
--->  Computing dependencies for py38-grpcio
--->  Fetching distfiles for py38-grpcio
--->  Verifying checksums for py38-grpcio
--->  Extracting py38-grpcio
--->  Configuring py38-grpcio
--->  Building py38-grpcio                               
Error: Failed to build py38-grpcio: command execution failed
Error: See /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_grpc/py38-grpcio/main.log for details.
Error: Follow https://guide.macports.org/#project.tickets if you believe there is a bug.
Error: Processing of port py38-grpcio failed
$ 

Main log py38-grpcio.log.txt uploaded.

???

[reneeotten (Renee Otten)]

installing a the port for a different Python version is of course not going to solve your problem. I strongly suggest you follow the advice by Ken, otherwise you're very likely on your own here.

[kencu (Ken)]

Thanks for doing the extra step and making the symlink, mouse.

I see your first error is now this:

:info:build third_party/abseil-cpp/absl/functional/internal/function_ref.h:26:1: error: unknown type name 'ABSL_NAMESPACE_BEGIN'
:info:build ABSL_NAMESPACE_BEGIN
:info:build ^
:info:build third_party/abseil-cpp/absl/functional/internal/function_ref.h:27:1: error: expected unqualified-id

Is it possible you have MacPorts version of abseil installed, and it is conflcting with the integrated one the py-grpcio port is trying to use?

I say that because I notice this in your build log:

:info:build /opt/local/include/absl/base/internal/invoke.h:181:21: note: 'Invoke' declared here
:info:build InvokeT<F, Args...> Invoke(F&& f, Args&&... args) {

and then:

$ port provides /opt/local/include/absl/base/internal/invoke.h
/opt/local/include/absl/base/internal/invoke.h is provided by: abseil

however, when I install the abseil port from MacPorts, and run the build of py-grpcio on my Mojave system, it works.

Nevertheless, perhaps try your build in trace mode to try to eliminate such things (or just deactivate abseil for the build):

sudo port clean py39-grpcio
sudo port -v -t destroot py39-grpcio

and if it builds, then

sudo port -v -t -s install py39-grpcio

BTW: the buildbot has finished building it, it seems, and there was success on all systems, so you can probably download the binary now if you're getting tired of this...

[mouse07410 (Mouse)]

installing a the port for a different Python version is of course not going to solve your problem.

Definitely not - because the very same error/problem occurs with Python-3.8 and Python-3.9.

however, when I install the abseil port from MacPorts, and run the build of py-grpcio on my Mojave system, it works.

Thank you! This seems to be the key. And not the SDK (just like I said ;). After installing abseil port (probably versions matter, as my Python installation had abseil due to another package' needs, brought in via pip):

$ sudo port uninstall py38-grpcio
Enter PIN for 'Certificate For PIV Authentication (xxxxxxx)': 
Note: It is not recommended to uninstall/deactivate a port that has dependents as it breaks the dependents.
The following ports will break:
 py38-tensorflow_macos @0.1.alpha3_0
 py38-tensorboard @2.5.0_0
Continue? [y/N]: y
Warning: Uninstall forced.  Proceeding despite dependencies.
--->  Deactivating py38-grpcio @1.39.0_0
--->  Cleaning py38-grpcio
--->  Uninstalling py38-grpcio @1.39.0_0
--->  Cleaning py38-grpcio
$ sudo rm /Library/Developer/CommandLineTools/SDKs/MacOSX11.sdk
$ sudo port install -v -sfn py38-grpcio
--->  Computing dependencies for py38-grpcio
--->  Fetching distfiles for py38-grpcio
--->  Verifying checksums for py38-grpcio
--->  Extracting py38-grpcio
--->  Configuring py38-grpcio
--->  Building py38-grpcio                               
--->  Staging py38-grpcio into destroot                  
--->  Installing py38-grpcio @1.39.0_0                   
--->  Activating py38-grpcio @1.39.0_0
--->  Cleaning py38-grpcio
$ 

Perhaps a dependency set should be updated for py38-grpcio and py39-grpcio to include abseil port?

BTW: the buildbot has finished building it, it seems, and there was success on all systems, so you can probably download the binary now if you're getting tired of this...

Yes, thanks - that too. That's what I did with py39-grpcio. ;-)

[kencu (Ken)]

I suspect there is a version mismatch between the version of abseil included in this port and the version in our port, and it stumbles over this change:

​https://github.com/abseil/abseil-cpp/commit/10cb35e459f5ecca5b2ff107635da0bfa41011b4

[mouse07410 (Mouse)]

I suspect there is a version mismatch between the version of abseil included in this port and the version in our port

I'm not sure I understand - if there's an "independent" port of abseil, why wouldn't py3x-grpcio use it as a dependency?

The above test showed that installing abseil port resolved the above problem... Or is it that abseil made an incompatible change that grpcio hasn't adjusted for yet? And the current Macports abseil port is "old" too, so they work together fine...?

[kencu (Ken)]

Replying to mouse07410:

I'm not sure I understand - if there's an "independent" port of abseil, why wouldn't py3x-grpcio use it as a dependency?

It uses it's own version, or at least tries to, because it is configured to do so by the upstream project.

The above test showed that installing abseil port resolved the above problem..

Not quite. As per your first bug report, you already had abseil installed, because the header was there. And your build failed.

You then said you installed abseil (which was apparently already installed) and it fixed your build, which is not adding up. Me, and every buildbot, built py-grpcio without installing abseil, so it is not needed to build pr-grpcio. In fact I thought having it installed might break rather than fix the build, but when I tried that, it didn't.

So what is really happening exactly on your system remains a mystery, which we may never solve, as you also have things installed in a non-standard fashion, and have things installed via pip as well.

Too many moving parts and confounding variables.

How about we close your ticket here as "works for me" for now, and see if anyone else finds this same issue?

[mouse07410 (Mouse)]

Not quite. As per your first bug report, you already had abseil installed, because the header was there. And your build failed.

Since Macports does not include all of the PyPI packages, some Python stuff on my machine(s) was/is installed via pip rather than Macports. So, the abseil copy that was present at the time of the bug report, was from PyPI rather than Macports.

You then said you installed abseil (which was apparently already installed) and it fixed your build, which is not adding up.

It does, because I replaced the PyPI copy of abseil with Macports copy of abseil. Apparently, they differed.

In fact I thought having it installed might break rather than fix the build, but when I tried that, it didn't.

What having it explicitly installed did was ensuring version consistency between the packages in question.

How about we close your ticket here as "works for me" for now, and see if anyone else finds this same issue?

Sure. I'm OK with that - except that I strongly urge reconsidering addition of abseil as a dependency for py-3x-grpcio to ensure it flushes out any possible "other" versions of abseil on the machine.

[kencu (Ken)]

Replying to mouse07410:

So, the abseil copy that was present at the time of the bug report, was from PyPI rather than Macports.

Oh, then that's the issue, for sure.

I strongly urge reconsidering addition of abseil as a dependency for py-3x-grpcio to ensure it flushes out any possible "other" versions of abseil on the machine.

I hear you, but I know that won't fly with the MacPorts' admins.

Great we got you sorted out.

[mouse07410 (Mouse)]

You finding the abseil conflict was the key. Thanks!