Upgrading GCC/ru

Данный документ проведет пользователя через процесс обновления GCC.

Введение
Эта статья о апгрейде GCC. Даунгрейд GCC может привести к нежелательным побочным эффектам. Обратитесь к разделу устранения проблем по поводу часто возникающих проблем.

Следующий раздел быстро введет вас в процесс обновления GCC (и того, как просто его сделать). Если вы хотите прочитать длинное объяснение причин, стоящих за обновлением GCC, продолжайте читать Объяснение обновления GCC.

Вкратце
Если вы обновляете GCC, то вам вообще не нужно ничего делать, кроме смены версии компилятора и пересборки libtool:

Если вы обновляете GCC с версии меньшей, чем 3.4.0 (для версий 3.x), либо 4.1, вам нужно еще запустить :

Проверьте текущую версию и удалите старую версию:

Вот и все. Наслаждайтесь новым компилятором!

Введение
GCC upgrading has always been mystified, with suggestions ranging from "You do not need to do anything" up to "You will need to rebuild your entire system twice". Most of this fear, uncertainty and doubt comes from the confusion surrounding ABI incompatibility. But first a quick pointer towards.

libtool и fix_libtool_files.sh
Earlier installments of GCC on Gentoo required you to run a specific command called. Some time ago, the execution of this command has been integrated in the package deployments itself (through the toolchain eclass) so there is no need for users to call this themselves anymore.

Причина, по которой нужно пересобирать libtool после обновления версий это потому, что главной функцией libtool является объединение кода, зависящего от платформы в общем интерфейсе, что позволяет приложениям использовать разделяемые библиотеки без нужды иметь дело с вещами, зависящими от платформы для разделяемых библиотек. Чтобы реализовать эту функцию, скрипт использует различные пути до библиотек, в которых есть жестко заданная информация о версии.

Изменения ABI
An ABI, or Application Binary Interface, is a set of conventions used by all tools that deal with binary representation of programs, including compilers, assemblers, linkers, and language runtime support (source: GCC Binary Compatibility). When the ABI used for binary applications and libraries is changed, you will risk getting linker errors or malfunctioning programs unless you rebuild all libraries that use C++ code.

Да, C++, поскольку в большинстве случаев несоответствия обнаруживаются на уровне двоичного интерфейса приложений C++. Если вы обновляетесь до GCC 4.1, или GCC 5.1, вы, вероятно, столкнетесь с проблемами в двоичном интерфейсе. Это так же объясняет почему мы снова использовали команду для  (от GCC 3 до GCC 4.1), или  (от GCC 4 до GCC 5.1).

Так почему же это нужно только до GCC 3.4.0/4.1/5? Это потому что с этой версии GCC использует обратно-совместимое ABI, и пересборка приложений и библиотек больше не требуется. Конечно, мы не можем дать вам гарантию, что так будет вечно, но если снова возникнет несоответствие, мы явно опишем этот случай здесь. В этом случае, скорее всего, будет увеличена версия библиотеки.

Особый случай C++11 (и C++14)
В то время как GCC (или точнее libstdc++) идет большими шагами вперед, гарантируя стабильность ABI, эта гарантия не распространяется на все части C++ в libstdc++. Формально, начиная с версии 3.4, GCC/libstdc++ только гарантируется стабильность C++98/C++03 ABI и не более. Это очень важно для пакетов, которые зависят от C++11. GCC даёт гарантию на стабильность C++11 ABI, начиная только с версии 5.1. Это означает, что переключение (даже незначительные) версии GCC (скажем, от 4.7.3 -> 4.7.4) может привести к поломке ABI для бинарных файлов, собранных из C++11 кода.

Более подробную информацию и некоторые примеры можно найти здесь:


 * https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61758
 * https://blogs.gentoo.org/blueness/2015/03/10/the-c11-abi-incompatibility-problem-in-gentoo/
 * https://stackoverflow.com/questions/16190269/g-always-backward-compatible-with-older-static-libraries/16196475#16196475
 * https://stackoverflow.com/questions/16190269/g-always-backward-compatible-with-older-static-libraries/16196475#16196475

Пересборка всего
Некоторые люди клянутся, что нужно пересобрать все пакеты на их системе при выходе новой версии GCC. Конечно, в этом нет смысла, так как многие приложения не используют GCC для процесса сборки и установки, и на них вообще не распространяется это изменение.

Это, однако, не означает, что они полностью неправы: новые версии GCC часто предлагают более хорошую поддержку набора инструкций процессора, а это может повлиять на производительность приложений в лучшую сторону. Хотя, чаще всего, данное улучшение очень незначительное, в некоторых случаях (особенно для приложений, сильно использующих процессор) это может привести к существенному улучшению.

There are also known cases where packages need to be built with the same compiler. Although these packages are usually bumped by package maintainers simultaneously (so that they are always built with the same GCC version) cherry-picking re-installs on these packages might prove to be troublesome. The various packages are a nice example on this matter.

libstdc++.so.6: version `GLIBCXX_3.4.15' not found
В процессе обновлений вы можете встретить ошибку, похожую на следующую:

Это означает, что вы пытаетесь собрать пакет более старой версией GCC, чем собирались библиотеки, от которых зависит пакет. Помните, мы говорили, что C++ ABI обратно совместим? Это так, но означает только, что для сборки приложений и линковки библиотек могут использоваться более новые (или те же самые) версии GCC (по сравнению с версией GCC, использованной для сборки этих библиотек).

Для пересоборки всех зависящих от libstdc++ смотрите пример команды revdep-rebuild в предыдущем разделе.

Какие пакеты определенно нужно пересобрать?
В следующей таблице приведены пакеты, которые нужно пересобрать, если они установлены, и причины этой необходимости.

Смотрите также

 * Upgrade GCC up to 4.1, the previous version of this document
 * Upgrading from gcc-4.x to gcc-5.x