Как создать приложение, которое требует обоих libstdc ++. таким образом 5, и libstdc ++. таким образом 6?
Немного академический этот вопрос, не так ли?;-) Моя точка зрения: Для меня интеграционный тест является тестом целой части, не, если две части из десять сочетаются. Наши шоу интеграционного теста, если основная сборка (содержащий 40 проектов) успешно выполнится. Для проектов у нас есть тонны модульных тестов. Самая важная вещь относительно модульных тестов на меня, что один модульный тест не должен зависеть от другого модульного теста. Таким образом для меня оба теста, которые Вы описываете выше, являются модульными тестами, если они независимы. Для интеграционных тестов это не должно быть важно.
4 ответа
Вы можете попытаться создать библиотеку-оболочку вокруг своей сторонней библиотеки: используйте статическую версию этой библиотеки + свяжите ее со стандартной статической библиотекой (-static-libgcc - убедитесь, что вы выбрали правильную версию через -L). Важно правильно закрыть эту библиотеку-оболочку, т.е. экспортировать только символы из исходной сторонней библиотеки, все остальное нужно скрыть. Таким образом, ваша библиотека-оболочка предоставит все необходимые символы для вашего приложения и инкапсулирует стандартные вещи внутри. Обратите внимание, что работа не гарантируется, особенно если некоторые операции с памятью разделяются между вашим кодом и сторонним кодом (например, вы выделяете память в своем коде и освобождаете ее от стороннего производителя) ... в таком случае единственным вариантом может быть сохранение этого третьего party lib в другом пространстве процесса.
Я не делаю ' Не думаю, что упомянутый выше динамический вариант будет работать, потому что вы столкнетесь с точно такой же проблемой - чуть позже.
В общем, лучше не смешивать двоичные файлы с разным временем выполнения в одном и том же пространстве процесса. Это почти всегда верный путь к катастрофе.
Спросите у своего поставщика более новую версию библиотеки, в которой используется что-то не слишком устаревшее. В противном случае вы можете увидеть, работает ли ваше новое приложение со старой версией библиотеки, и при необходимости перенести его обратно. Попытка иметь две разные версии одной и той же библиотеки требует больших усилий, и я не думаю, что вы найдете приемлемое решение.
Хотя легко связать libstdc ++. So.6 и libstdc ++. So.5 с вашим приложением одновременно, его поведение в значительной степени будет неопределенным, поскольку символы взяты из любого библиотеку в основном случайно.
Лучший способ добиться успеха IMO - это создать собственное приложение на основе вашей сторонней библиотеки в старой системе (которая использует совместимый gcc, например, gcc 3.3), и позволить ему общаться с вашим основное приложение через IPC (например, разделяемая память). Таким образом, нет
Если вы не хотите хранить libstdc ++. So.5 в вашей целевой системе, это просто: используйте флаг gcc -static, чтобы связать libstdc ++. A с вашим приложением-оболочкой.
Хотя один из приведенных до сих пор подходов может работать, я думаю, будет безопаснее сказать, что вы не можете сделать это напрямую надежным способом. Если вы пишете оболочку, используя API, полностью основанные на C (только C-совместимые структуры, память, управляемая malloc / free, и т. Д.), То вы можете использовать решение pobedim. Однако, если вам нужно обмениваться структурами C ++, это небезопасно, поскольку, даже если вы можете сделать ссылку, разные реализации стандартных библиотек будут использоваться для одних и тех же объектов. Кроме того, C ++ ABI может быть несовместимым между базами кода на основе .5- и .6 (я точно не помню, как несколько лет назад произошло основное изменение Gnu C ++ ABI, связанное со стандартными именами библиотек).
Я думаю, что самый безопасный подход к решению этой проблемы - использовать многопроцессорный подход с некоторой разновидностью IPC между вашим приложением и процессом сервера ресурсов / вычислений, построенным на рассматриваемой библиотеке. Вы можете использовать CORBA, D-Bus, Sun RPC или какой-либо специальный протокол для каналов или сокетов для выполнения этой работы. Я сделал это, когда пытался использовать 32-битный код с закрытым исходным кодом в 64-битных приложениях, и он работает достаточно хорошо. Вы увидите снижение производительности, но также полностью обойдете проблемы, связанные с попыткой смешать среды выполнения C ++ в одном процессе.