Changes in Protobuf C++ versions and their implications on OSI

[doganulus]

Realized that Google's official Protobuf implementation depends on libabsl, their Abseil C++ Library after Protobuf v22. Not only a dependency, but also they expose absl types at the public API. Now this has some consequences as follows.

1. This creates an ODR violation risk for statically linked applications. For example, if an OSI application has another dependency on a project using absl statically. Then, it will cause an ODR.
2. Hence, Google's Protobuf implementation after v22 is safely usable as a shared object only.

I wonder what the OSI project's recommendation is for this situation, where the project still uses pre-v22 versions and recommends static linkage in the documentation.

Some related issues and PRs:

• Check different Protobuf versions #765
• Support more protobuf versions in GitHub workflow #766

[pmai]

Just to clarify the recommendations from the OSI side: The recommendation to use static linking strictly only applies to the FMI use-case (i.e. OSMP), as FMI both - for good reasons - mandates that FMUs should be self-contained, and this supports the presence of multiple versions of e.g. OSI in one process via isolated DLLs/SOs (for Linux this requires specific linker settings to cause the dynamic loader to keep the SOs internal symbols isolated).

For use inside an application that only has one OSI version present, and does not load FMUs, nothing speaks against dynamic linking.

That the path of both C++ and Protobuf in this regard more or less will lead to separate compilation being even more of a joke than it already is, and stable ABIs being a thing of the past, is another topic entirely. OTOH that ship seems to have sailed and we live in a world where every language is a dependency hell.