Как обеспечить соблюдение/кто должен обеспечить (разработчик приложения? разработчик библиотеки?), как следует или НЕ сл ⇐ Linux

[Anonymous]

Я много гуглил и изучал... пока не могу найти ясности.
Я пытаюсь понять правильный инженерный подход для проблемы управления версиями Linux ELF/разделяемой библиотеки в экосистеме C++.
Предположим, у меня такая ситуация:

• Код: Выделить всё

  app

  ссылается непосредственно на libcore.so.1
• одну из зависимостей приложения, libphysical.so, ссылается на libcore.so.2

• Код: Выделить всё

  another dependency, 

  librender.so

  Код: Выделить всё

  , also links to 

  libcore.so.2`

Предположим, что libcore.so.1 и libcore.so.2 ABI-несовместимы и имеют разные SONAME.
Мои вопросы заключаются не только в том, «что делает загрузчик?», но также в том, «какова правильная ответственность за проектирование, чтобы избежать или минимизировать коллизии символов и взрывы в одном и том же процессе?»
На данный момент я понимаю, что динамический загрузчик Linux загрузит ОБЕИ эти библиотеки, потому что у них разные SONAME. Но некоторые из их символов могут быть названы одинаково, а не изолированы автоматически, верно? Полагаю, конфликты символов все еще могут произойти?

Если да, то кто несет ответственность за предотвращение этого беспорядка? разработчики libcore? разработчики приложения? в libcore.so должно быть какое-то обнаружение во время выполнения? Должны ли они немедленно дать сбой при обнаружении другой библиотеки?
Я ищу рекомендации по обычной лучшей практике в хорошо спроектированной экосистеме общих библиотек C++/Linux:

• поведение загрузчика ELF
• SONAME/ожидания управления версиями
• проблемы видимости/коллизий символов
• и, самое главное, архитектурное правило для общих зависимостей, которые могут использоваться как приложением, так и зависимыми от него библиотеками

Я не спрашиваю, как обойти это с помощью LD_PRELOAD; Я спрашиваю, какой подход к дизайну является правильным.
Если я что-то не понял, дайте мне знать, и я перефразирую.