Статически связывать частную библиотеку с публичной, чтобы скрыть символы

Рассмотрим следующее:

  • Я разрабатываю статическую библиотеку X в С++, которая внутренне использует известную статическую библиотеку Y v2.0;
  • Я хочу распространять только одну библиотеку X ', то есть X с Y, статически связанным/объединенным для внутреннего использования;
  • Разработчик хочет использовать X 'в своем исполняемом файле;
  • Кроме того, ему нужен Y v1.0 (а не v2.0, как и я);
  • У v1.0 и v2.0 есть некоторые общие символы, и некоторые из этих общих символов также ведут себя по-разному.

Я разработал X со строгим требованием использовать Y v2.0 для своего внутреннего бизнеса. Это означает, что я никоим образом не могу вернуться к Y v1.0.
С другой стороны, разработчик имеет аналогичные ограничения для использования Y v1.0.

Как вы уже можете утверждать, возникает вопрос: как я могу связать Y внутри X без экспорта символов Y, чтобы избежать столкновений? Y хорошо установлен, и, возможно, я не хочу изменять его исходный код или строить настройки (если они общедоступны).

Чтобы добавить больше вещей на Землю, я занимаюсь разработкой SDK, который наверняка понадобится некоторым сторонним библиотекам, скажем, zlib. В моем развитии я буду полагаться на zlib v1.2.3.4.5.rc6, потому что я широко и успешно использовал и тестировал его, и я не могу позволить себе тестировать/исправлять SDK, если я меняю версию.
Все статически или динамически связанные библиотеки, предлагаемые SDK, должны скрыть сторонние статические.

Потенциальный клиент может подвергнуться аналогичным ограничениям (ему нужен zlib v7.8.9), так как я могу избежать конфликтов символов? Опять же, возможно, без изменения исходного исходного кода (namespacing и т.д.).

Чтобы усложнить ситуацию, SDK является мультиплатформенным, подразумевая, что мне нужны разные способы решения проблемы в зависимости от платформы (Windows, Linux, Mac OS, iOS, Android,...) и используемого компилятора (например, MSVС++ и g++).

Спасибо.

Обновление
Кажется, я VENDOR2 этого вопроса: Связь с несколькими версиями библиотеки
Ответ bstpierre кажется жизнеспособным решением, но я не уверен, что он работает, или если он может быть воспроизведен на ОС, кроме * nix.

Ответы

Ответ 1

У меня была эта проблема много раз со статическими libs, совсем недавно с MSVCRT. При использовании одного исполняемого файла правило One Definition становится мешающим, как указывает один комментатор. На самом деле не обойти это, о чем я могу думать, если не использовать патчи. И вам придется сделать это "глубоко" - поймать все внутренние ссылки, которые статическая библиотека Y (zlib) делает для своих внешних объектов связи.

В этом случае я бы предложил использовать динамическую библиотеку (DLL или SO). Это добавит немного сложности развертывания. Но он предоставляет исполняемый "брандмауэр", позволяющий глобальным объектам с тем же именем проживать в каждом двоичном файле без столкновения. Тем не менее, это может создавать проблемы, если у обоих приложений и DLL есть конфликтующие сторонние зависимости. Тем не менее, возможно, лучший вариант.