2012-02-06 2 views
5

Вот ситуация, у меня есть кодовая база C++, использующая недавний GCC (4.3.3), но мне нужно связать ее с старой библиотекой, которая была построена с использованием GCC 3.2. 3. Нет новой версии доступной библиотеки, я не могу обойтись без нее, и она закрыта, поэтому ее невозможно перестроить.Смешивание C++ ABI для построения против устаревших библиотек

Это похоже на проблему, поскольку между GCC 4.3.3 и 3.2.3 существует несовместимость ABI, поэтому я пытаюсь понять, какие у меня варианты для решения этой проблемы.

Несколько дополнительных деталей:

  • я могу восстановить все, что в моем коде с -fabi-версии = 1, чтобы получить правильную версию ABI, но я завишу от некоторых новых функций от libstdC++ версии 6.
  • Все зависимости библиотеки C++ за пределами кодовой базы являются открытыми исходными кодами, поэтому я могу их перестроить по мере необходимости, за исключением этой библиотеки.
  • Множество зависимостей библиотеки C, которые невозможно перестроить или их будет сложно перестроить.
  • старая библиотека, кажется, зависят от некоторой libstdC++ версии 5 Особенности

Я до сих пор пытался:

  • Перестроить все кодовые и зависимые библиотеки C++ с -fabi-версией = 1 и ссылками против libstdC++ версии 6. Это не удается с помощью нескольких неопределенных ошибок символов для стандартных символов библиотеки C++.
  • То же, что и выше, но дополнительно ссылка в общей библиотеке для libstdC++ 5, это устраняет проблемы компоновщика, но, похоже, приводит к смешению двух версий во время выполнения внутри старой библиотеки и вызывает сбои.

Я читаю эту страницу: http://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html, которая, как представляется, может смешивать версии C++ ABI в приложении для удовлетворения различных зависимостей между библиотеками. Похоже, здесь это не очень хорошо работает, если я ничего не упускаю.

Любые идеи?

+0

Параметры компоновщика '-Bsymbolic' и' --exclude-libs' должны помочь вам, если вы ставите старую старую libstdC++ в общую библиотеку. –

ответ

3

Ok, ваш обходной путь заключается в следующем:

  • написать интерфейс "C" в старой библиотеке C++, компилировать с 3.2.3, так что будет работать.
  • Теперь вы можете использовать интерфейс C в новом компиляторе.

Вы можете написать код C++ «обертка» вокруг библиотеки C, чтобы использовать его как C++, но этот код будет создан в новом компиляторе.

+1

Конечно, это имеет недостаток, заключающийся в добавлении куча кода клея, но имеет преимущество в работе с ЛЮБОЙ парой компиляторов/версий C. – kibibu

+0

Это похоже на разумный подход. Если я создам из него общую библиотеку, она все равно будет зависеть от старой библиотеки libstdC++. У меня не будет такой же проблемы? Или мне следует статически связывать старые версии? –

+0

После того, как вы сделали еще больше копания, кажется правильным, это статически связать libstdC++ с более старым GCC в эту общую библиотеку.Однако, как мне кажется, недостаточно ссылок на это, потому что у вас будет такая же проблема, как и раньше, когда символы разделяются по границе библиотеки. Я думаю, что вы можете устранить любую вероятность этого, выполнив dlopen внутри приложения и используя RTLD_NOW | RTLD_DEEPBIND | RTLD_LOCAL. –

Смежные вопросы