Обновление GCC

From Gentoo Wiki
Jump to:navigation Jump to:search
This page is a translated version of the page Upgrading GCC and the translation is 70% complete.
Outdated translations are marked like this.
Other languages:

GCC upgrades should generally be handled gracefully with Portage and the usual Gentoo tools, see next section . If ever there are more involved updates that require user intervention, they should be accompanied by a corresponding news item , that should be read and followed.

Обратите внимание, что понижение версии GCC может иметь нежелаемые побочные эффекты. Обратитесь к секции Устранение проблем для информации по часто встречаемым проблемам.

Quick guide to GCC upgrades

Большинство обновлений GCC так же просты, как смена версии компилятора (тут с 10.3.0 на 11.2.0) и пересборка dev-build/libtool :

root # emerge --ask --oneshot sys-devel/gcc
root # gcc-config --list-profiles 
[1] x86_64-pc-linux-gnu-10.3.0 *
[2] x86_64-pc-linux-gnu-11.2.0
root # gcc-config 2
root # source /etc/profile
root # emerge --ask --oneshot --usepkg=n dev-build/libtool

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

root # gcc --version
root # emerge --ask --depclean sys-devel/gcc:10.3.0

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

Подробное руководство по обновлению GCC

Обновление GCC всегда сопровождалось различными мистификациями, с предложениями, варьирующимися от «пользователям ничего не нужно делать» до «пользователи должны дважды пересобрать всю систему». Неопределённость обычно вызывалась путаницей с несовместимостью ABI, что ныне довольно редко вызывает какие-либо проблемы.

libtool

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

Смотрите bug #88596 .

Изменения ABI

До GCC 5.1

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

При обновлении до GCC 4.1 или GCC 5.1 скорее всего возникнут проблемы с ABI. Чтобы избежать этого, необходимо запустить команду revdep-rebuild для библиотеки libstdc++.so.5 (при обновлении с GCC 3 на GCC 4.1) или libstdc++.so.6 (при обновлении с GCC 4 до GCC 5.1).

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

Это необходимо сделать только для обновлений GCC 4.1/5.1, так как начиная с этих версий GCC использует обратно совместимый ABI, благодаря чему пропадает необходимость в пересборке приложений и библиотек. Конечно же, нельзя дать на это полную гарантию, но, когда вновь возникнет несовместимость, мы непременно опишем этот случай здесь и выпустим новость. В этом случае, скорее всего, будет увеличена версия библиотеки libstdc++.so .

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

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

Понижение версии GCC

For the aforementioned reasons, if downgrading GCC or choosing an older slot with gcc-config , it is necessary to run revdep-rebuild to catch libstdc++ consumers requiring newer symbols:

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

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

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

Пакет Причина необходимости пересборки
dev-build/libtool libtool использовал жёстко заданные пути ко внутренним библиотекам GCC, см. bug #88596 .
root # emerge --ask --oneshot --usepkg=n --verbose dev-build/libtool

Также известны случаи, когда пакеты должны быть собраны одним и тем же компилятором (к примеру, различные qt-* пакеты). Эти пакеты чаще всего обновляются сопровождающими пакета одновременно (поэтому они всегда будут собираться одной и той же версией GCC). Выборочная переустановка таких пакетов часто сопровождается проблемами.

Пересборка всего

Совет
This isn't necessary but is described here so people know how to do it thoroughly if they desire.

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

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

Кроме таких "небольших" плюсов, пересборка всего с нуля может быть обязательна в некоторых случаях, чтобы исправить проблемы без очевидных причин.

Некоторые проблемы с программами исконно трудны в диагностике, но их можно решить простой пересборкой одного или больше соответствующих пакетов. Если подобная проблема возникла после обновления GCC и сохранилась после применения revdep-rebuild как показано выше (и после пересборки прочих очевидно связанных пакетов), полная пересборка системы может решить этот вопрос.

Самый "безопасный" (но также затратный по времени) способ этого достичь - использование опции --emptytree ( -e ) для emerge, чтобы пересобрать системные пакеты и мир :

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

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

(Заметьте, что команды выше пересоберут пакеты в системном наборе дважды, что необходимо, дабы быть "абсолютно уверенными", что каждый пакет был собран в одинаковой [предположительно] "безпроблемной" среде. Любые проблемы, что сохраняются после этого - действительно баги, о которых нужно сообщить, или серьёзные проблемы с конфигурацией системы.)

Устранение проблем

пересборка boost

Если dev-libs/boost нужно пересобрать, вы получите следующее сообщение об ошибке:

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

Пересобрать можно с помощью:

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

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

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

undefined reference to `__cxa_call_terminate@CXXABI_1.3.15'

This is usually a result of compiling a package that had its dependencies built with a newer GCC version than with the current one selected. An example output might be:

КОД undefined reference to __cxa_call_terminate@CXXABI_1.3.15 
/usr/lib/gcc/x86_64-pc-linux-gnu/13/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib64/libgtest.so: undefined reference to `__cxa_call_terminate@CXXABI_1.3.15'

What this means is the package that is emerging is building with, for example, GCC 13 but the package that provides libgtest.so was built with a newer version of GCC, 14 in this case.

If hitting this, first, if not deliberately downgrading GCC, make sure to select the latest toolchain versions:

root # binutils-config latest && gcc-config latest && . /etc/profile

If deliberately downgrading GCC, read on. The solution to this problem is rather simple but can be hard to figure out if the package providing the file is unknown. Portage supports emerging file paths directly so running emerge -1 /path/to/file.so might detect the file.

In the example, try emerging /usr/lib64/libgtest.so

root # emerge -1a /usr/lib64/libgtest.so 
Calculating dependencies -
 
!!! '/usr/lib/libgtest.so' is not claimed by any package.
... done!

Unfortunately the file needed was not claimed, but another utility exists to find files installed by packages, Pfl . Using e-file , it is possible to find the package that installs the needed file.

user $ e-file libgtest.so 
...
[I] dev-cpp/gtest
        Seen Versions:          1.13.0 1.14.0
        Portage Versions:       1.13.0 1.14.0 9999
        Installed Versions:     1.14.0(Fri Nov 24 04:35:00 2023)
        Homepage:               https://github.com/google/googletest
        Description:            Google C++ Testing Framework
        Matched Files:          /usr/lib/libgtest.so; /usr/lib64/libgtest.so
...

In this case, dev-cpp/gtest is causing the build issue, re-merging it with:

root # emerge --ask --oneshot dev-cpp/gtest

should fix the issue and allow the continuation of emerging the original package.

Заметка
For larger packages, it is likely to encounter this more than once while rebuilding a package with a lower version of GCC, keep following the above steps to eventually succeed in recompiling the package with GCC 13

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

Внешние ресурсы

Ссылки

Retrieved from " /wiki/Upgrading_GCC/ru&oldid=1386681 "