Обновление GCC

From Gentoo Wiki
Jump to: navigation, search
This page is a translated version of the page Upgrading GCC and the translation is 52% complete.

Outdated translations are marked like this.
Other languages:
English • ‎español • ‎italiano • ‎русский • ‎中文(中国大陆)‎ • ‎日本語 • ‎한국어

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

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


This section is a quick primer on GCC upgrades (and how easy they are). More details are given in the next section, GCC upgrading explained.

Most GCC upgrades are as simple as switching the compiler version (here from 5.4.0 to 6.4.0) and rebuilding libtool:

root #emerge --ask --oneshot sys-devel/gcc
root #gcc-config --list-profiles
[1] x86_64-pc-linux-gnu-5.4.0 *
[2] x86_64-pc-linux-gnu-6.4.0
root #gcc-config 2
root #source /etc/profile
root #emerge --ask --oneshot --usepkg=n sys-devel/libtool
If you are upgrading from gcc 4.x to gcc 5.x or later, additional instructions apply; please see then the separate page Upgrading from gcc-4.x to gcc-5.x.

Check the current version number and then uninstall the old version:

root #gcc --version
root #emerge --ask --depclean =sys-devel/gcc-5.4.0

After that, verify system integrity running revdep-rebuild:

root #revdep-rebuild

Enjoy the new compiler!

Объяснение обновления GCC

GCC upgrading has always been mystified, with suggestions ranging from "users do not need to do anything" to "users will need to rebuild the entire system twice". Most of this fear, uncertainty and doubt comes from the confusion surrounding ABI incompatibility, something that nowadays rarely happens (and when it does, it will be announced). But first a quick pointer towards libtool.


The reason we need to rebuild libtool after the upgrade of gcc versions is because of its main purpose: libtool is a toolset that aggregates platform-specific code in a generic interface, allowing applications to build against shared libraries without needing to deal with the platform-specific aspects of shared libraries. To fulfill its function properly, the libtool script uses various library locations that have hard-coded gcc version information in them.

Изменения 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.

Yes, C++, since most incompatibilities occur within the C++ ABI. If you are upgrading to GCC 4.1, or GCC 5.1, you would probably encounter ABI issues. To prevent this, the revdep-rebuild command should be run against the libstdc++.so.5 library when moving from GCC 3 to GCC 4.1, or libstdc++.so.6 when moving from GCC 4 to GCC 5.1.

root #revdep-rebuild --library 'libstdc++.so.6' -- --exclude gcc

So why is this only needed up to GCC 4.1/5.1? That's because from that version onward, GCC uses a forward-compatible ABI, which removes the need for rebuilding applications and libraries. Of course, guarantees can never be given indefinitely, but when an incompatibility occurs again, we'll definitely document it here and release a news item. In that case, the version of the libstdc++.so library will probably be increased.

Особый случай 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 кода.

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

Какие пакеты определенно нужно пересобрать?

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

Package Rebuild needed because ...
sys-devel/libtool libtool application has hardcoded paths towards GCC internal libraries.
sys-devel/llvm depends on exact gcc version, may encounter linking errors with other ebuilds making use of LLVM (e.g. media-libs/mesa) if not rebuilt.
sys-devel/clang depending on exact gcc version, may be affected by sys-devel/llvm.
root #emerge --ask --oneshot --usepkg=n --verbose sys-devel/libtool sys-devel/llvm sys-devel/clang

Some collections of packages need to be built with the same compiler (for example, the various qt-* packages). Such packages are usually bumped by package maintainers simultaneously, so they will always be built with the same GCC version. Cherry-picking re-installs on these packages might prove to be troublesome.

Rebuilding everything

Some people swear that they need to rebuild every single package on their system when a new GCC version is made available. Of course, that doesn't make sense, since there are many applications that are not using GCC for their build and install process anyhow, so they would never be affected by such changes.

That, however, doesn't mean they are completely incorrect: newer GCC versions often include better support for the processors' instruction set, which might influence the performance of some applications in a positive way.

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 --emptytree (-e) option of emerge to rebuild the system set and then the world set:

root #emerge --ask --emptytree --usepkg=n @system
root #emerge --ask --emptytree --usepkg=n @world

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 dev-libs/boost needs to be rebuilt, one will get the following error message:

root #emerge ...
checking for the Boost _____ library... no
configure: error: cannot find the flags to link with Boost _____

One can rebuild with:

root #emerge --ask --oneshot --usepkg=n --verbose dev-libs/boost

libstdc++.so.6: version `GLIBCXX_3.4.15' not found

В процессе обновлений вы можете встретить ошибку, похожую на следующую:

Код GLIBCXX_x.y.z not found
cmake_bootstrap_28021_test: /usr/lib/gcc/i486-pc-linux-gnu/4.1.2/libstdc++.so.6:
version `GLIBCXX_3.4.11' not found

This means that you are trying to build a package with an older GCC version than that with which some depending libraries were built. Remember when we told that the C++ ABI is forward-compatible? That is true, but it ensures only that higher (or same) GCC versions can be used when building applications and linking libraries (compared to the GCC version used to build those libraries).

To rebuild all the packages depending on libstdc++, see the revdep-rebuild instructions above.

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