[package] grpc/>1.38: Shared libs not found

[AlvaroFS]

I'm building google-cloud-cpp and protobuf as shared libs for a project. When tit comes to build google-cloud-cpp it crashes when running grpc_cpp_plugin with: error while loading shared libraries: libprotoc.so.3.17.1 cannot open shared object file It works fine when using protobuf as a static lib but seems like a problem with grpc setting de LD_LIBRARY_PATH variable when using executables built by conan on other packages' build stage.

[SpaceIm]

This issue doesn't come from grpc recipe but google-cloud-cpp recipe. Full log, conan profile, commands etc would be appreciated.

[AlvaroFS]

Sorry for the lack of information. The following conanfile will reproduce the error:

[requires]
google-cloud-cpp/1.31.1
protobuf/3.19.2
grpc/1.44.0

[options]
google-cloud-cpp:shared=True
protobuf:shared=True

[generators]
cmake

running mkdir build && conan install . -if build --build missing

[parequena]

I'm having same problem on here

[jan-kelemen]

grpc recipe is also involved in this problem. It produces a binary grpc_cpp_plugin which is not runnable at all when the shared option is enabled. With grpc:shared=True it requires the following additional shared objects for it to start:

libgrpc_plugin_support.so.1.50 => not found
libprotocd.so.32 => not found
libprotobufd.so.32 => not found

But it has no RPATH or RUNPATH set so it doesn't find these. To make it worse, libgrpc_plugin_support.so.1.50 comes from the grpc package, and the other two come from the protobuf package.

grpc_cpp_plugin is needed to be able to generate files with the protoc binary coming from the protobuf package.

[jcar87]

Hi @AlvaroFS, @parequena, @jan-kelemen -

would you be able to provide the following information:

• conan profile (need to know the platform, gcc version, settings, etc) - assuming Linux since RPATH/RUNPATH are mentioned
• conan version and conan command executed that fails
• is the problem building google-cloud-cpp/1.31.1 from source when both grpc and protobuf are shared, or is there any other command/action that results in an error?

@jan-kelemen - libprotocd.so.32 the d suffix would indicate one of these packages is in debug mode, right? a full conan command to reproduce, alongside profiles, will help

thanks!

[jan-kelemen]

Hi @jcar87,

I ran into this problem just using the grpc package, not the google-cloud-cpp package. The underlying problem is that grpc_cpp_plugin isn't runnable when grpc:shared=True is enabled. Anyway I'll try.

First to address your question regarding Release/Debug mode, it doesn't matter, it fails in both, in Release it just searches for libprotoc.so.32, which is also not found.

The google-cloud-cpp/1.31.1 package doesn't want to build fully on my machine, but the build succeeds far enough that I can demonstrate the problem.

Conan version:

conan --version
Conan version 1.58.0

Here is the conan profile, which I have stored in file named conan_profile:

[settings]
arch=x86_64
build_type=Release
compiler=gcc
compiler.cppstd=gnu17
compiler.libcxx=libstdc++11
compiler.version=11
os=Linux

Here is the conanfile.txt:

[requires]
google-cloud-cpp/1.31.1
protobuf/3.21.4
zlib/1.2.13

[options]
# grpc:shared=True

And finally the command: conan install -pr conan_profile conanfile.txt --build missing

If you run this command, soon in the beggining of the output, there will be lines as such:

[  5%] Running C++ protocol buffer compiler on /mnt/work/lo/.conan/data/google-cloud-cpp/1.31.1/_/_/build/993d899d84650887581c24eec1b0a87753ed6152/external/googleapis/src/googleapis_download/google/api/label.proto
[  5%] Running C++ protocol buffer compiler on /mnt/work/lo/.conan/data/google-cloud-cpp/1.31.1/_/_/build/993d899d84650887581c24eec1b0a87753ed6152/external/googleapis/src/googleapis_download/google/api/http.proto

If we now uncomment the shared option, so that the conanfile looks like this:

[requires]
google-cloud-cpp/1.31.1
protobuf/3.21.4
zlib/1.2.13

[options]
grpc:shared=True

And run the same command again:

[  7%] Running gRPC C++ protocol buffer compiler on /mnt/work/lo/.conan/data/google-cloud-cpp/1.31.1/_/_/build/993d899d84650887581c24eec1b0a87753ed6152/external/googleapis/src/googleapis_download/google/type/interval.proto
[  7%] Running gRPC C++ protocol buffer compiler on /mnt/work/lo/.conan/data/google-cloud-cpp/1.31.1/_/_/build/993d899d84650887581c24eec1b0a87753ed6152/external/googleapis/src/googleapis_download/google/api/field_behavior.proto
/mnt/work/lo/.conan/data/grpc/1.45.2/_/_/package/d88b982d15fbc5a8f751d711c8babe33f0403e9a/bin/grpc_cpp_plugin: error while loading shared libraries: libgrpc_plugin_support.so.1.45: cannot open shared object file: No such file or directory
--grpc_out: protoc-gen-grpc: Plugin failed with status code 127.
/mnt/work/lo/.conan/data/grpc/1.45.2/_/_/package/d88b982d15fbc5a8f751d711c8babe33f0403e9a/bin/grpc_cpp_plugin: error while loading shared libraries: libgrpc_plugin_support.so.1.45: cannot open shared object file: No such file or directory
--grpc_out: protoc-gen-grpc: Plugin failed with status code 127.

This is applicable for gRPC/1.50.1 as well.

Please let me know if you need anything else.

[blackBeaRR]

Hi everyone! Are there any known solutions? I'm getting the same error and I have to build grpc as shared library by some reason.

[jan-kelemen]

@blackBeaRR call the gRPC compiler trough a bash script in which you extend the LD_LIBRARY_PATH variable with the value of where the gRPC shared objects are, something along lines of https://cmake.org/pipermail/cmake/2009-March/028092.html and then execute the script instead of the compiler

it works but it's far from a good solution

[blackBeaRR]

@jan-kelemen error happens during conan install command (but in my case nvidia triton library instead of google-cloud-cpp) and not during compilation of my own project. I understand the reason of this error, but I don't know how to call some bash script during conan install command after grpc and before triton processing. Do you mean modify conan recipe for that or something else?

Thanks for help anyway!

[jan-kelemen]

@blackBeaRR in that case the solution i mentioned isn't applicable, you would have to modify the nvidia triton recipe to make it work

you could extend the LD_LIBRARY_PATH before calling conan install, but for that you would have to know the folder in which conan installs the shared objects