Например, могу ли я смешать набор библиотек, скомпилированных, скажем, в GCC-4.6, с GCC-4.9.
Я знаю, что разные "породы" компиляторов, такие как VS, не могут быть с MinGW, но могут ли разные поколения одного и того же компилятора? Возможны ли проблемы? Если да, то?
Различные поколения одного и того же компилятора иногда могут быть совместимы друг с другом, но не всегда. Например, GCC 4.7.0 изменен его C/C++ ABI, что означает, что библиотеки, скомпилированные с 4.7.0+ и 4.7.0-, вряд ли будут совместимы друг с другом (поэтому в вашем примере библиотека, скомпилированная с 4.6, не будет быть совместимым с библиотекой, скомпилированной с 4.9). В данном выпуске компилятора также могут быть ошибки ABI, как это произошло в GCC 4.7.0/4.7. .1:
Версии GCC 4.7.0 и 4.7.1 внесли изменения в стандартную библиотеку C++, которые повлияли на ABI в режиме C++11: элемент данных был добавлен в std::list, изменив его размер и изменив определения некоторых функций-членов, и Конструктор перемещения std::pair был нетривиальным, что изменило соглашение о вызовах для функций с аргументами std::pair или возвращаемыми типами. Несовместимости ABI были исправлены для GCC версии 4.7.2, но в результате код C++11, скомпилированный с помощью GCC 4.7.0 или 4.7.1, может быть несовместим с кодом C++11, скомпилированным с другими версиями GCC и с C++. Код 98/C++03, скомпилированный с любой версией.
Страница политики и рекомендаций GCC ABI указывает, что они пытаются поддерживать прямую совместимость, но не обратная совместимость:
Управление версиями дает последующим выпускам двоичных файлов библиотеки возможность добавлять новые символы и добавлять функциональные возможности, сохраняя при этом совместимость с предыдущими выпусками серии. Таким образом, двоичные файлы программ, связанные с первоначальным выпуском двоичного файла библиотеки, по-прежнему будут работать правильно, если двоичный файл библиотеки будет заменен тщательно управляемыми последующими двоичными файлами библиотеки. Это называется прямой совместимостью.
Обратное (обратная совместимость) неверно. Невозможно взять двоичные файлы программы, связанные с последней версией двоичного файла библиотеки в серии выпусков (с добавленными дополнительными символами), заменить их в исходном выпуске двоичного файла библиотеки и остаться совместимыми по ссылке.
На этой странице также есть несколько довольно длинных объяснений системы управления версиями, которую GCC использует для обозначения различных версий заданных компонентов, а также объяснение управления версиями самого GCC:
Разрешенные изменения
Следующее приведет к увеличению вспомогательного номера версии библиотеки, скажем, с libstdc++.so.3.0.4 до libstdc++.so.3.0.5.
Добавление экспортированного глобального или статического члена данных
Добавление экспортированной функции, статической или невиртуальной функции-члена
Добавление экспортированного символа или символов путем дополнительных экземпляров
Возможны другие допустимые изменения.
Запрещенные изменения
Следующий неполный список приведет к увеличению основного номера версии библиотеки, например, с libstdc++.so.3.0.4 до libstdc++.so.4.0.0.
Изменения в ABI компилятора gcc/g++
Изменение размера экспортируемого символа
Изменение выравнивания экспортированного символа
Изменение макета экспортированного символа
Изменение искажения экспортированного символа
Удаление экспортированного символа
Изменение свойств наследования типа путем добавления или удаления базовых классов
Изменение размера, выравнивания или макета типов, указанных в стандарте C++. Они не обязательно могут быть созданы или иным образом экспортированы в двоичный файл библиотеки и включают все необходимые аспекты локали, а также такие вещи, как std::basic_streambuf и др.
Добавление явного конструктора копирования или деструктора в класс, который в противном случае имел бы неявные версии. Это изменит то, как компилятор работает с этим классом в операторах возврата по значению или параметрах: вместо передачи экземпляров этого класса в регистры компилятор будет вынужден использовать память. Дополнительную информацию см. в разделе, посвященном соглашениям о вызовах функций и API-интерфейсам документации C++ ABI.
Обратите внимание на выделенный жирным шрифтом бит. В идеальном мире версии GCC с одним и тем же основным номером выпуска были бы бинарно-совместимы. Это не идеальный мир, поэтому очень тщательно проверьте, прежде чем смешивать версии компиляторов, подобные этой, но в целом вы, вероятно, будете в порядке.
Вы можете смешивать сгенерированные двоичные файлы из разных компиляторов или разных версий одного и того же компилятора только в том случае, если они совместимы с ABI (двоичным интерфейсом приложения).
Вещи как:
все являются частью ABI.
Если что-то из этого изменится, вы обнаружите, что либо получаете ошибки компоновщика, сбои или другие формы неожиданного поведения. Как правило, поставщики компиляторов часто пытаются поддерживать по крайней мере обратную совместимость со старой версией, но это не гарантируется. Как уже говорили другие, вы должны либо прочитать документацию, либо просто перекомпилировать все.
