Не очень трудно повредить двоичную назад-совместимость библиотеки DSO / общей библиотеки с интерфейсом C++. Тем не менее есть ли инструмент статического анализа, который может помочь обнаружению таких повреждений ABI, если это дало два различных набора заголовочных файлов: те из более раннего состояния DSO и тех из текущего состояния (и возможно DSOs также)? И бесплатные и коммерческие предложения продукта приветствуются.
Если бы это могло бы также предупредить о плохих методах, например, подставляемых функциях и приняло значение по умолчанию параметры функции в интерфейсах DSO, это было бы большим.
Полагаю, вы знакомы с этим учебником: Проблемы совместимости двоичных систем с C++, если не , то прочтите его!
Я слышал об этом инструменте: http://ispras.linuxbase.org/index.php/ABI_compliance_checker, однако никогда не тестировал и не использовался, так что не высказывайте своего мнения.
Также это может вас заинтересовать: Создание библиотеки с обратно совместимым ABI, использующей Boost
ABI - Двоичный интерфейс приложения сводится к тому, как компилятор транслирует исходный код в распознаваемую машиной инструкцию. Одна и та же строка исходного кода может быть транслирована в конечной программе в разный поток байт.
статический анализатор, пробегающий по исходному коду, не сможет предсказать, как компилятор будет его транслировать. такое решение принимается в кодировке или настройках компилятора. поэтому я не верю, что статический анализатор поможет вам в этом случае.
Помню, на работе использовали GCC XML для проверки бинарной совместимости. В основном он генерирует xml представление дерева объектов компилятора. Теория гласит, что если xml эквивалентен, то бинарная совместимость была сохранена.
.Единственный безопасный способ сделать это - экспортировать вашу библиотеку, используя C-интерфейс. Библиотека на Си++ совместима только с одним компилятором, который вы используете для ее компиляции.