Как создать приложение, которое требует libstdc++.Итак.5 и libstdc++.Итак.6?
Я хочу предварить это важным замечанием, что Я не программист на C / C++, и знаю мало о том, как связь библиотек работает в C.
наш код использует libstdc++.Итак.6 (gcc 3.4, я думаю). У нас есть сторонние предварительно скомпилированные библиотеки (с закрытым исходным кодом), которые используют libstdc++.Итак.5 (gcc 2.что-то или 3.2, я думаю). Это на linux. У нас есть как .а и .Итак, версия третьей стороны lib.
возможно ли построить наше приложение с 3rd party libs? Как? Возможно ли создать / запустить наше приложение без libstdc++.Итак.5 установили наши наши машины, как?
если я забыл какую - то важную информацию, пожалуйста, дайте мне знать-я вряд ли знаю, что имеет отношение к этому материалу. Я понимаю, что полный ответ, вероятно, будет невозможен; я действительно ищу направление и руководство. Статическая ссылка это, динамическое то, перестроить, предварительно построенный так-то, переключиться на версию x, или символическая ссылка quizdoodle, так далее.
обновление:
мы пытались использовать dlopen с RTLD_LOCAL чтобы изолировать стороннюю библиотеку от остальной части нашего приложения. Это, кажется,в основном работала, мы остались с большими утечками памяти по неизвестным причинам. Мы подозреваем это, когда зовем dlopen, сторонняя библиотека тянет символы, такие как malloc из уже загруженных .Итак.6, и все запутывается.
для хихиканья мы попытались поместить стороннюю библиотеку в LD_PRELOAD, затем запустил наше приложение, и утечки памяти, похоже, полностью исчезли.
4 ответов
вы можете попытаться создать библиотеку-оболочку вокруг вашей сторонней библиотеки: используйте статическую версию этой библиотеки + свяжите ее со статической стандартной библиотекой (- static - libgcc-убедитесь, что вы выбрали правильную версию через-L). Главное, что нужно сделать, это правильно закрыть эту библиотеку обертки, я.e следует экспортировать только символы из исходной сторонней библиотеки, все остальное должно быть скрыто. Таким образом, библиотека wrapper будет предоставлять все необходимые символы для вашего приложения и инкапсулируйте стандартный материал внутрь. Примечание. не гарантируется работа, особенно если некоторые операции памяти совместно используются между кодом и сторонним кодом (например, вы выделяете память в коде и освобождаете ее в стороннем коде)... в таком случае единственным вариантом может быть, чтобы это 3-й партии lib в другом пространстве процесса.
Я не думаю, что динамический вариант, упомянутый выше, будет работать, потому что вы получите точно такую же проблему - чуть позже.
вообще лучше не надо смешайте двоичные файлы с различным временем выполнения в одном и том же пространстве процесса. Это почти всегда приводит к катастрофе.
попросите своего поставщика о более новой версии библиотеки, которая использует что-то не ужасно устаревшее. В противном случае вы можете увидеть, работает ли ваше новое приложение со старой версией библиотеки и при необходимости перенести его обратно. Попытка иметь две разные версии одной и той же библиотеки требует боли, и я не думаю, что вы найдете приемлемое решение.
в то время как легко связать оба libstdc++.Итак.6 и libstdc++.Итак.5 для вашего приложения в то же время его поведение будет в значительной степени неопределенным, потому что символы берутся из любой библиотеки в основном случайно.
лучший способ добиться успеха IMO-создать собственное приложение вокруг вашего стороннего lib на старой системе (которая использует совместимый gcc, например, gcc 3.3), и пусть он общается с вашим основным приложением через IPC (например. разделяемая память.) Сюда, нет.
Если вы не хотите сохранить libstdc++.Итак.5 в вашей целевой системе, тогда это просто: используйте флаг GCC-static для связи libstdc++.a к приложению-обертке.
хотя один из подходов, приведенных до сих пор, может работать, я думаю, что безопаснее сказать, что вы не можете сделать это напрямую надежным способом. Если вы пишете оболочку, используя полностью API на основе C (только c-совместимые структуры, память, управляемая malloc / free и т. д.), то вы могли бы использовать решение pobedim. Однако, если вам нужно обменять структуры C++, это небезопасно, так как, даже если вы можете сделать ссылку, различные реализации стандартных библиотек будут использоваться на одном и том же объекты. Кроме того, C++ ABI может быть несовместимым.5 - а .6-based code bases (я не помню точно, как основные изменения Gnu C++ ABI произошли несколько лет назад, связанные со стандартными именами библиотек).
Я думаю, что самый безопасный подход к решению этого-использовать многопроцессорный подход с каким-то IPC между вашим приложением и процессом ресурса/вычислительного сервера, построенным на соответствующей библиотеке. Вы можете использовать CORBA, D-Bus, Sun RPC или какой-то специальный протокол по трубам или розетки для работы. Я сделал это при попытке использовать 32-разрядный код с закрытым исходным кодом в 64-разрядных приложениях, и он работает достаточно хорошо. Вы увидите хит производительности, но вы также полностью обойдете проблемы, присущие попытке смешать время выполнения C++ в одном процессе.