grpc plugin with shared=True doesn't work

[alex1234567890123456789]

This one is a bit complicated. I need to use the shared versions of grpc and protobuf in my project. However, the shared grpc_cpp_plugin will not run, because it can't find the shared proto libs. It does not have an RPATH/RUNPATH set.

I was able to compile a static version of grpc_cpp_plugin by adding [options] *:shared!=False to my build profile (note the ! is required or else the grpc requires recipe overrides the tool_requires recipe's shared option). However, at configure time, the shared version is found, not the static version.

Without using cmake-conan, this actually works, because the CMakeToolchain generator adds the path to the static grpc plugin to the PATH in CMakePresets.json. Grpc uses find_program to discover grpc_cpp_plugin. I realize find_program does not work properly in cmake-conan. However, I don't think find_program needs to be used here - the Conan grpc package knows where grpc_cpp_plugin is, so it could set the exact path instead of finding itself - but it would need to know to set the path to the tool_requires version and not the requires version.

[jcar87]

Hi @alex1234567890123456789

Thanks for reporting this.

We have a fix still in draft for this - it should work with conan_provider.cmake as it is here: https://github.com/jcar87/grpc-cmake-conan/blob/main/cmake/conan_provider.cmake (mostly the changes from #626)

I have a project reproducing the original issue with the fix here: I've been able to reproduce this issue in https://github.com/jcar87/grpc-cmake-conan

I was able to compile a static version of grpc_cpp_plugin by adding [options] *:shared!=False to my build profile (note the ! is required or else the grpc requires recipe overrides the tool_requires recipe's shared option).

This doesn't sound right - recipes in Conan Center are all shared=False by default, so you should only need to set *:shared=True in the host profile - options in the host profile do not affect anything in the build profile. You can have a look at https://github.com/jcar87/grpc-cmake-conan/blob/main/CMakePresets.json#L20-L21 - which passes this https://github.com/jcar87/grpc-cmake-conan/blob/main/conan_host_options as an "overlay" to the default profile

However, I don't think find_program needs to be used here - the Conan grpc package knows where grpc_cpp_plugin is, so it could set the exact path instead of finding itself - but it would need to know to set the path to the tool_requires version and not the requires version.

The Conan grpc package only knows about "its own" grpc_cpp_plugin - but when the graph resolves to a different one in the build context (via tool_requires) it does not know where the "other" package root is, so it relies on find_program (which itself relies on Conan's cmake toolchain). We can probably improve this - but the way cmake-conan works via the dependency provider still has some limitations.

Either way - with the proposed fix which is still in a draft PR, you should be able to correctly resolve the plugin in the build context with find_program as it is - let me know if this solves your issue, otherwise very happy to help :)

[jcar87]

hi @alex1234567890123456789 - any luck with the proposed fix?

[alex1234567890123456789]

sorry for the delay, I was under the weather last week. I'm going to try to test that out this week, but we do currently have a workaround (making everything static) so it's not top priority anymore.