Build gRPC-C++ with custom BoringSSL prefix

[Ivan Pizhenko]

Hi,

I am facing following situation: I need to use in the my application both GRPC and another library which is tied to OpenSSL, and does not link with BorinSSL. Specifying both of them  on the linker arguments leads to some linker errors. Please explain, how can I build gRPC so that BoringSSL gets built with custom symbol prefix (so that it does not shadow OpenSSL) and have the rest of the GRPC and my application which uses GRPC to use that prefix too. In the BorongSSL build instructions I have seen that there is possibility to build it with custom prefix on symbols ( Building BoringSSL (googlesource.com) ), so I assume this is potentially possible. I am using CMake (and cannot use Bazel). OS: Linux, Windows. Toolchains:  VS2017, GCC.

Thanks you in advance, Ivan.

[Ivan Pizhenko]

I've tried to specify following on the GRPC cmake invocation:

-DBORINGSSL_PREFIX_SYMBOLS=ON -DBORINGSSL_PREFIX=MY_BSSL_PREFIX

but cmake prints following in the end:

CMake Warning:
  Manually-specified variables were not used by the project:

    BORINGSSL_PREFIX
    BORINGSSL_PREFIX_SYMBOLS

what is the correct way to pass these option down to BoringSSL and and make GRPC count on the too?

четвер, 1 квітня 2021 р. о 18:07:24 UTC+3 Ivan Pizhenko пише:

[Jan Tattermusch]

HI Ivan,

I think your best option is to build grpc  (and the other library) against openssl. You can actually build grpc without boringssl when using cmake (and use either a system installation of openssl or openssl installed under a prefix).

An example of that is in one of our distribtests: https://github.com/grpc/grpc/blob/4f81c3b706deed639cf4ecc9f3fc97da36230899/test/distrib/cpp/run_distrib_test_cmake.sh#L21

Ad boringssl symbol prefixing:

This is something that we actually use internally for our objc build (see e.g. https://github.com/grpc/grpc/blob/26f85ca2d9fd1df6129afbfadc3dbfb3e8176d4e/src/objective-c/BoringSSL-GRPC.podspec#L205) so it does work,

but it seems more complicated to do than the option I mentioned above (and it's also not something that we officially support).

I'm not sure what exactly is causing the problem you mentioned above,  but I think you could try to specify BORINGSSL_PREFIX not as a cmake option, but as a compile time define (e.g. through cmake's add_definitions: https://cmake.org/cmake/help/latest/command/add_definitions.html).

[Ivan Pizhenko]

Thanks, I will try to build it with OpenSSL.

понеділок, 12 квітня 2021 р. о 10:20:26 UTC+3 Jan Tattermusch пише: