Upgrading GCC/ru

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

Please note that downgrading GCC might have unwanted side effects. Refer to the troubleshooting section for some commonly reported issues.

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

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

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

After that, verify system integrity running revdep-rebuild:

Enjoy the new compiler!

Объяснение обновления GCC
Обновление GCC всегда было какой-то мистикой, с предположениями от "Вам ничего не нужно знать" до "Вам нужно дважды пересобрать всю свою систему". Большинство страха, неуверенности и сомнений проистекает из проблем, связанных с несовместимостью ABI. Но, сначала кратко о.

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

Изменения ABI
ABI, или Двоичный интерфейс приложений, это набор соглашений, используемых всеми инструментами, работающими с бинарным видом программ, например, компиляторы, ассемблеры, линкеры и поддержка рантайма для языков (источник: Бинарная совместимость GCC). Когда ABI, используемый для бинарных приложений и библиотек меняется, появляется риск получить ошибку компоновщика, либо неработающие программы, если только вы не пересоберете все программы, использующие код C++.

Да, 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 для процесса сборки и установки, и на них вообще не распространяется это изменение.

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

Apart from such "benign" benefits, rebuilding everything from scratch may be necessary in some cases to fix problems that don't seem to have any obvious cause.

Some software problems are inherently difficult to diagnose and yet could be solved by simply rebuilding one or more appropriate packages. If such a problem has arisen following a GCC upgrade and persists after using the revdep-rebuild approach described above (and after rebuilding any other obviously relevant packages), a complete system rebuild may be the answer.

The "safest" (but also most time-consuming) way to accomplish this is to use the   option of emerge to rebuild the system set and then the world set:

Users are urged to try this approach before reporting any bugs that might have been caused by a GCC upgrade.

(Note that the commands above will cause the packages in the "system" set to be rebuilt twice, which is necessary to be absolutely certain that every package gets built in the same [presumably] "problem-free" environment. Any problems that remain after doing this are due to either "genuine bugs" that should be reported or poor system configuration.)

rebuild of boost
If needs to be rebuilt, one will get the following error message:

One can rebuild with:

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
 * Fedora's 'Changes/GCC6' Wiki Page