Использовать библиотеки C ++ из одного и того же VS, скомпилированные в разное время / команды - совместимость с ABI?

Повторюсь: я ищу совместимость ABI между библиотеками той же версии Visual-C ++!

Мы хотим смешивать и сопоставлять некоторые внутренние библиотеки DLL C ++ от разных команд, созданные в разное время из разных файлов проекта. Из-за длительного времени сборки мы точно хотим избежать больших монолитных сборок, когда каждая команда повторно компилирует исходный код библиотеки другой команды.

При использовании библиотек DLL C ++ с интерфейсами C ++ это скорее < / a> очистить что вы можете сделать это, только если все библиотеки DLL скомпилированы с помощью одного и того же компилятора / Visual Studio. версия.

Для меня не совсем очевидно, что что должно быть таким же, чтобы обеспечить совместимость с ABI.

  • Очевидно, что отладку (_DEBUG) и выпуск (NDEBUG) нельзя смешивать, но это также очевидно из того факта, что они связаны с разными версиями общей среды выполнения.
  • Нужна ли вам точно такая же версия компилятора или достаточно, чтобы результирующая DLL ссылалась на одну и ту же разделяемую среду выполнения C ++, то есть в основном на одну и ту же распространяемый? (Я думаю, что статика не летает при передаче полных объектов C ++)
  • Is there a documented list of compiler (and linker) options that need to be the same for two C++ DLLs of the same vc++ version to be compatible?
    • For example, is the same /O switch necessary - does the optimization level affect ABI compatibility´? (I'm pretty sure not.)
    • Или обе версии должны использовать один и тот же _ 4_ переключатель?
    • Или _ 5_ ...?

По сути, я хотел бы создать набор (мета) данных для связи с Visual-C ++ DLL, который описывает совместимость с ABI.

Если есть различия, то сейчас я сосредоточен только на VS2015.


abi visual-c++ visual-studio-2015 visual-c++-2015
person Martin Ba    schedule 21.10.2016    source источник
comment
В общем, вы должны стараться обеспечить одну и ту же версию CRT для всех двоичных файлов. В противном случае это может сработать, но не гарантировано. Я не могу ответить на настройки компилятора C ++, но рекомендуется стандартизировать все настройки компилятора / компоновщика в ваших командах.   -  person Chris O    schedule 21.10.2016
comment
_ITERATOR_DEBUG_LEVEL - это тоже вещь, которая должна быть равна, поскольку она влияет на компоновку объекта std-lib.   -  person Martin Ba    schedule 21.10.2016
comment
github.com/microsoft/vcpkg/blob/master/docs/ users / triplets.md   -  person Martin Ba    schedule 03.07.2020

Ответы (1)


arrow_upward
2
arrow_downward

Я думал об этом в последние дни, и то, что я сделал, - это попытаться увидеть, существуют ли какие-то варианты использования, в которых разработчикам уже нужно было классифицировать свою сборку C ++, чтобы убедиться, что двоичные файлы совместимы.

Одно из таких мест - Собственные пакеты от nuget. Итак, я просмотрел там один пакет, а именно cpprestsdk:

Двоичные файлы в загружаемый пакет, разделенный следующим образом:

native\v120\windesktop\msvcstl\dyn\rt-dyn\x64\Release\
        ^      ^         ^      ^    ^     
  VS version   |       not sure |    uses cpp-runtime dynamically
               |               lib itself dynamic (as opposed to static)
    or WinXP or WinApp(WinRT?)

Я вытащил это из этого примера, потому что не смог найти других документов. Я также знаю, что каталог сборки бинарных файлов boost разделен аналогичным образом.

Итак, чтобы перейти к списку метаданных для определения совместимости с ABI, я могу предварительно перечислить следующее:

  • VC version (that is, the version of the C and CPP runtime libraries used)
    • one point here is that e.g. vc140 should be enough nowadays - given how the CRT is linked in, all possible bugfixes to the versioned CRT components must be ABI compatible anyway, so it shouldn't matter which version a given precompiled library was built with.
  • чистый родной | управляемый (/ CLI) | WinRT
  • как потребляется ЭЛТ (статически / динамически)
  • разрядность / платформа (Win32, x64, ARM и т. д.)
  • Версия выпуска или отладки (т.е. на какую версию CRT мы ссылаемся)
  • плюс: _ITERATOR_DEBUG_LEVEL ... если все соглашаются со значениями по умолчанию, хорошо, если проект не работает, он должен объявить это

Кроме того, мое наилучшее предположение по следующим пунктам:

  • /O не имеет значения - мы постоянно смешиваем и сопоставляем двоичные файлы с разными настройками оптимизации - в частности, это работает даже для объектных файлов в одном и том же двоичном файле.
  • /volatile - так как это вещь генерации кода, мне трудно представить, как это может сломать ABI
  • /EH - кроме опции отключения всех исключений, и в этом случае вы, очевидно, не можете вызвать что-либо, что выдает, я вполне уверен, что это спасение с точки зрения ABI: здесь есть возможные подводные камни, но я думаю, что они не могут действительно быть отнесенным к ABI compat. (Возможно, некоторые сложные цепочки обратных вызовов можно назвать несовместимыми с ABI, не уверен)

Другие:

  • Соглашение о вызовах по умолчанию (/G..): я думаю, что это может сломаться во время связывания, когда искаженные символы экспорта и объявления заголовков не совпадают.
  • /Zc:wchar_t - прерывается во время компоновки (на самом деле он совместим с ABI, но символы не отображаются.)
  • Включить RTTI (/GR) - не слишком уверен в этом - я никогда не работал с этим отключенным.
person Martin Ba    schedule 26.10.2016