Trying to link grpc-cpp on Windows after abseil static build migration fails

[kkraus14]

Solution to issue cannot be found in the documentation.

• I checked the documentation.

Issue

See logs from arrow-cpp build here: https://dev.azure.com/conda-forge/84710dde-1620-425b-80d0-4cf5baca359d/_apis/build/builds/551576/logs/480

It looks like it's trying to find abseil 20220623 symbols in the grpc lib and as far as I can tell those should be static linked into the grpc lib. The Arrow Flight shared library being built doesn't use abseil directly in any way or link to it via CMake.

I'm not sure exactly what's going on and this may not be a grpc issue, but figured I'd open an issue here to start.

cc @hmaarrfk @h-vetinari

Installed packages

n/a

Environment info

n/a

[h-vetinari]

We ran into a similar issue with zlib (non-private targets within grpc-cpp). This causes errors later when trying to look for abseil (or zlib) again.

[kkraus14]

Will try adding the libabseil static into the host section as a stopgap, thanks

[h-vetinari]

Yeah, this affects all builds that are consuming grpc-cpp, which is why I'm trying to fix this ASAP in #215. I'm struggling to get the windows tests to run though, c.f. conda-forge/zstd-feedstock#64 & https://discourse.cmake.org/t/questions-about-find-package-cli-msvc/6194/6.

[kkraus14]

I don't think the fix in #215 will suffice unfortunately, where if you're depending on another package that depends on a different version of abseil, say google-cloud-cpp 1.40.1 (which is what the conda-forge pinning is currently at), then I believe you end up in a situation where that package finds the wrong version of abseil at runtime since an older version of abseil-cpp and libabseil-static can coexist with different versions.

[h-vetinari]

then I believe you end up in a situation where that package finds the wrong version of abseil at runtime since an older version of abseil-cpp and libabseil-static can coexist with different versions.

No, that shouldn't be possible.

In any case, I've also sharpened the run-dep to pin the version from host, see d8b1195

[kkraus14]

No, that shouldn't be possible.

In any case, I've also sharpened the run-dep to pin the version from host, see d8b1195

Apologies, you are correct that the version is matching properly. That being said I'm still seeing similar issues with google-cloud-cpp where it gets similar linking errors to grpc-cpp related to abseil.

[kkraus14]

Still running into the same problems: https://dev.azure.com/conda-forge/84710dde-1620-425b-80d0-4cf5baca359d/_apis/build/builds/551996/logs/273

I believe the solver won't use the new builds since the abseil pinnings haven't been migrated quite yet: https://github.com/conda-forge/conda-forge-pinning-feedstock/blob/main/recipe/conda_build_config.yaml#L348-L350

So it looks like in the arrow-cpp grpc 1.46 builds the solver is grabbing grpc-cpp 1.46.4-h1b7795f_1 which doesn't enforce the libabseil-static runtime and while libabseil-static 20211102.0-cxx11_h253ae9c_2 is in the same environment it doesn't matter since grpc-cpp 1.46.4-h1b7795f_1 has been built with a static linked libabseil-static 20220623.0.

Seems like these packages are broken and we should mark them as broken or put in a repodata patch to add a libabseil-static runtime dependency?

[h-vetinari]

I'm fine with marking them as broken. That silent run-dependence is really unfortunate. Beyond that, I see two other (possibly complementary approaches):

• Migrate to newest abseil (though I believe arrow is still missing a dep for that)
• Pin 1.46 to <1.46.4, since all 1.46.3 builds were for the old setup

[h-vetinari]

@kkraus14
I removed the workaround for the rundeps again in the last builds. Please let us know if anything goes wrong, but 🤞 that it's ok now - I added a test for picking up the builds from CMake, but it's possible or even likely that this can still be extended.