feedback: integration in Lichtblick/ASAM-OSI-Utilities

[jdsika]

I only got the integration running with the proposed changes. Did I do something wrong or is that ok?
https://github.com/lichtblick-suite/asam-osi-utilities/pull/8/changes

[jdsika]

I can fix it in osi-utilities but this is my agents opinion:

› I wonder why this is not handled by the cmakelist in osi-cpp or the subsequent repository of open-simualtion-interface?

• Great question — it should ideally be handled upstream, but there’s a real-world gap here.

Why it isn’t handled in osi-cpp or upstream OSI yet

1. Protobuf’s Abseil dependency is relatively new and version‑dependent.
   Older Protobuf releases didn’t require Abseil for logging, and many projects still assume protobuf::libprotobuf is self‑contained. On macOS/Homebrew, protobuf now brings in Abseil, but the CMake target doesn’t always propagate those link requirements in a way downstream static libs inherit.
2. osi-cpp builds static libs (open_simulation_interface_pic.a), and static libraries do not carry their own link dependencies the way shared libs do.
   So even if osi-cpp links protobuf::libprotobuf, that still doesn’t guarantee the final executable will link Abseil unless those dependencies are explicitly propagated.
3. CMake target export patterns in upstream OSI are conservative.
   The submodule links protobuf::libprotobuf, but it doesn’t add Abseil explicitly because:
   • it isn’t directly referenced in their code
   • it’s not “visible” at the CMake level unless protobuf exposes it via INTERFACE_LINK_LIBRARIES
   • and in many environments (Linux, older protobuf), it works without Abseil

In short:
This is a downstream static‑linking edge case triggered by newer Protobuf + macOS/Homebrew. It’s not strictly a bug in osi-cpp, but it is a missing propagation that only shows up in certain toolchain combinations.

If you want, I can also open a small upstream note/PR against osi-cpp so they can consider adding Abseil linkage when protobuf requires it.

› so it would be a fix in osi-cpp and not in the opensimulation interface repo?

• Yes — the most appropriate upstream fix would be in osi-cpp, not the Open Simulation Interface (OSI) spec repo.

Why osi-cpp is the right place

• The failure happens when linking the C++ library produced by osi-cpp.
• The OSI spec repo only contains .proto definitions and documentation. It doesn’t build C++ targets or manage link dependencies.
• osi-cpp owns the CMake logic that creates open_simulation_interface_* libraries and links Protobuf.

So ideally:
osi-cpp should either:

1. Propagate Abseil (when needed) via its own CMake targets, or
2. Ensure protobuf::libprotobuf link requirements are fully exported.

Since we can’t change the submodule in this PR, we patched it at the top-level, but the canonical fix should land in osi-cpp.

If you want, I can draft a minimal upstream PR/patch suggestion for osi-cpp to make this permanent.

[jdsika]

I will add this to my cmake:

if (APPLE AND NOT LINK_WITH_SHARED_OSI)
    message(WARNING "Homebrew protobuf removed static library builds due to Abseil dependencies. "
                    "See: https://github.com/Homebrew/homebrew-core/commit/5c6d1bc12fafdae166757e2efd6afb6142ff610a "
                    "For Homebrew builds on macOS, prefer -DLINK_WITH_SHARED_OSI=ON.")
endif ()

[jdsika]

Just letting you know that I am also not managing the dynamic linking:

Totally fair to sanity‑check — and yes, it is building the shared OSI library now. The log you pasted proves it:

Linking CXX shared library libopen_simulation_interface.dylib

So dynamic linking is happening, but it still fails because the shared OSI library itself is missing Abseil at link time. Shared vs static doesn’t change that — the
missing symbols must be resolved when libopen_simulation_interface.dylib is built.

Here’s the chain of facts in the repo:

• macOS CI now configures with -DLINK_WITH_SHARED_OSI=ON in .github/workflows/ci_build.yml.
• src/CMakeLists.txt links shared OSI when that flag is on:
  • target_link_libraries(OSIUtilities PRIVATE open_simulation_interface::open_simulation_interface)

So yes, OSIUtilities is using the shared OSI library.

Why it still fails:
osi-cpp v3.8.0‑rc1 doesn’t link Abseil, and Homebrew’s Protobuf doesn’t export Abseil either — so the shared library link still breaks. That’s why I added the
top‑level Abseil link shim in CMakeLists.txt (after add_subdirectory(lib/osi-cpp)), so open_simulation_interface itself links Abseil.

If you want, I can add a CI log line to print the actual link command (e.g., VERBOSE=1) to confirm Abseil libs are on the link line, but the fix is now in place.

Let me know if you want me to tweak it to only apply on macOS or leave it cross‑platform as it is now.