On Thu, Sep 7, 2023 at 7:24 PM Benjamin Barenblat <bba...@debian.org> wrote: > I will do an upload of 20230802.0 to experimental today, but I don’t > think it fixes this issue. scoped_mock_log depends on symbols in > GoogleMock, but there’s no good way to express those dependencies in a > hypothetical libabsl_scoped_mock_log.so since libgmock.so doesn’t exist. Thanks for the upload and the information. I'm going to check it soon.
> The way upstream (Google) intends for all this to work is for protobuf > to link its Abseil and GoogleMock dependencies statically. Is that > possible? It is possible, but not recommended. If abseil gets (security) fixes, protobuf will not get it like in the case of loading fresh shared libraries. Also it seems protobuf configure process looks for shared version of abseil. Need to double check. > If not, I have some alternative ideas (like building a > libabsl_scoped_mock_log.so without a DT_NEEDED entry for GoogleMock), > but they all seem like hacks. I’m also open to other ideas if anybody > has them. I'm not sure how to handle this properly for everyone. I think I will solve this on the protobuf side. Use static linking with abseil and record with the build process which version was used. The hard way would be to bundle an abseil source tarball with protobuf and use its shared version of libraries from a private location only for protobuf. The first should get precedence for which abseil should export static linking possibilities of scoped_mock_log in its cmake files. Regards, Laszlo/GCS
