Учтите следующее:
Я разработал 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), так как я могу избежать столкновения символов? Опять же, возможно без изменения исходного исходного кода (пространства имен и т. Д.).
Ситуация усложняется тем, что SDK является мультиплатформенным, что подразумевает, что мне потребуются разные способы решения проблемы в зависимости от платформы (Windows, Linux, Mac OS, iOS, Android, …) и используемого компилятора (например, MSVC ++ и g ++). ,
Спасибо.
Обновить
Кажется, я VENDOR2 этого вопроса:
Связывание с несколькими версиями библиотеки
Ответ bstpierre кажется жизнеспособным решением, но я не уверен, что он работает или его можно воспроизвести в других операционных системах, кроме * nix.
У меня была эта проблема много раз со статическими библиотеками, в последнее время с MSVCRT. Как указывает один комментатор, с одним исполняемым файлом мешает правило «Одно определение». Я действительно не могу обойти это, о чем я могу думать, за исключением исправления двоичных файлов. И вам придется делать это «глубоко» — перехватывать все внутренние ссылки, которые статическая библиотека Y (zlib) делает на свои собственные объекты внешних связей.
В этом случае я бы предложил использовать динамическую библиотеку (DLL или SO). Это добавит немного сложности развертывания. Но он предоставляет исполняемый «межсетевой экран», позволяющий глобальным объектам с одинаковыми именами находиться в каждом двоичном файле без коллизий. Тем не менее, это может создать проблемы, если и приложение, и DLL имеют конфликтующие сторонние зависимости. Все-таки, наверное, лучший вариант.
Других решений пока нет …