Problems with dynamic linking

[clemenshabedank]

Describe the feature

The OSI library must offer the possibility that within a C++ program (one process) two or more different OSI versions can be used simultaneously as dynamic libraries (shared libraries).
This is not possible due to the "Custom Options" [1] in the current OSI version 3.X.X with the used FileOption (see [2]).
and leads to the following runtime error:

[libprotobuf FATAL external/com_google_protobuf/src/google/protobuf/extension_set.cc:93] Multiple extension registrations for type "google.protobuf.FileOptions", field number 81000.
unknown file: Failure
C++ exception with description "Multiple extension registrations for type "google.protobuf.FileOptions", field number 81000." thrown in the test body.

[1] https://developers.google.com/protocol-buffers/docs/proto#customoptions
[2]

open-simulation-interface/osi_version.proto.in

Line 54 in 6ae62d6

optional InterfaceVersion current_interface_version = 81000;

Important note: As discussed a reminder for the v4.0 release (not backward compatible). This issue is uploaded by me on behalf of BMW.

@pmai @ThomasNaderBMW FYI

[ReinhardBiegelIntech]

We at openPASS are also interested in having this problem solved :-)

Is there a fix planned for v4.0.0 or is it still in discussion?

[ReinhardBiegelIntech]

I did some tests and found the "Multiple extension registrations" error to disappear, if I just don't access the extension.
So if I don't use this code (or use it only once in the process), the usage of multiple libraries seems to be fine.

[ThomasNaderBMW]

Feedback from my colleague Markus Schönbeck (sry it is German):

• Wenn man nicht den Sourcecode aller Komponenten unter Kontrolle hat, kann es dennoch zu diesem Problem kommen, wir haben keine Garantie, dass dies nicht benutzt wird.
• Letztendlich sollte dieser Fehler vollständig ausgeschlossen werden (wie von OpenPath anscheinend ja auch gewünscht).
• Etwas, was vorhanden ist, nicht zu benutzen, weil es sonst zu Problemen kommt, ist ein Design-Fehler ((selbst wenn der Workaround bei OpenPath zu funktionieren scheint).

[ReinhardBiegelIntech]

Related: protocolbuffers/protobuf#6029

[PhRosenberger]

Related: OpenSimulationInterface/osi-sensor-model-packaging#87

[pmai]

Since this came up in discussions again todyay, the way to avoid problems with multiple registrations on Linux, while still allowing multiple versions of OSI to coexist is to link all users statically against both protobuf and OSI libraries, and to use the -Bsymbolic linker flag (-Wl,-Bsymbolic on the gcc command line) when generating the shared objects (i.e. the FMUs), which prevents global ELF symbol interposition from the executable into the shared object.

The problem occurs when an executable (i.e. the simulator) includes a copy of protobuf and OSI, and FMUs (i.e. shared objects) are loaded into the simulator without proper isolation flags being used in the ldopen call; then global symbol references in the shared object are first looked up against the executable image, and only if not found there are looked up in the shared object. This is called ELF symbol interposition, which allows an executable to interpose common definitions of plugins, but which wreaks havoc in our case.

The alternative on Linux is to link everything dynamically (i.e. shared) against the exact same version of protobuf and OSI shared libraries, which then works out, but is against the whole idea of FMI and OSI in that everything depends on exactly identical versions/binaries and is not independent anymore.

On Windows the problem does not occur, here static linking everything just works, because there is no ELF symbol interposition (and actually only specially marked symbols, not all global symbols, partake in DLL dynamic linking, which can present its own problems, but is of no concern in our use cases).

[ClemensLinnhoff]

Thank you for the explanation @pmai!
How would you set the linker flag when using cmake .. and cmake --build .?
I tried setting set(CMAKE_STATIC_LINKER_FLAGS "-Wl,-Bsymbolic") and alternatively set_target_properties(OSMPDummySource PROPERTIES PREFIX "" LINK_FLAGS "Wl,-Bsymbolic") or target_link_options(OSMPDummySensor PRIVATE "-Wl,-Bsymbolic") in the CMakeLists in both OSMPDummySource and OSMPDummySensor. But the error File already exists in database: osi_version.proto still occurs during co-simulation with OpenMCx.

[pmai]

For cmake 3.13 and higher, the portable way to add the flags would be either

add_link_options("LINKER:-Bsymbolic")

at project level or

target_link_options(OSMPDummySensor PRIVATE "LINKER:-Bsymbolic")

at target level (prior to 3.13 you'd use add_libraries/target_link_libraries).

This ensures that the proper way to pass the linker flags to the linker is used for each compiler, i.e. -Wl is only for gcc, clang uses -Xlinker.

You also have to ensure that everything is statically linked, including protobuf itself.

[pmai]

Just to expand on the latter point:

You also have to ensure that everything is statically linked, including protobuf itself.

This usually requires your own custom build of protobuf, as you need a static library that has itself been built with -fPIC (i.e. as DSO-ready position-independent code), which is needed (depending on many circumstances, so just generalizing here) to link it into a shared object. Usually either no static library exists, or if it exists it has been built for inclusion into an executable, where -fPIC is not needed.

[ClemensLinnhoff]

Thank you very much for your last comment, @pmai. That's it!
I had do get protobuf and build it from source with running ./configure --disable-shared CXXFLAGS="-fPIC" before running make.
So in detail:
Download protobuf, unzip and go to the extracted folder. Then run the following commands:

./configure --disable-shared CXXFLAGS="-fPIC"
make
sudo make install
sudo ldconfig

I did not have to change anything in the CMakeLists, so -Bsymbolic did not have to be set.