Изменение переменной CHOST

Данная статья объясняет, как изменить переменную CHOST для существующей системы.

Изменение CHOST может доставить много «головной боли» и серьезно испортить систему. Зачем тогда нужно данное руководство, если это может привести к хаосу?

Существуют ситуации, когда изменение переменной CHOST необходимо, например, при обновлении библиотеки glibc до версии 2.4, которая поддерживает nptl, пользователь узнается, что текущий CHOST — это i386, что делает использование nptl невозможным. В данном случае не так уж и много возможностей, и изменение CHOST одна из них.

Проблемы могут возникнуть, даже после выполнения этих инструкций, так что, пожалуйста, внимательно читайте и очень тщательно выполняйте их. В данном примере переменная CHOST изменится с i386 на i686. Пожалуйста, скорректируйте команды в соответствии с конкретной ситуацией.

Обновление make.conf

To start out with the CHOST variable change, edit the /etc/portage/make.conf file and add/change the CHOST value to suit the requirements.

ФАЙЛ /etc/portage/make.conf

CHOST="mips64-unknown-linux-gnuabin32"

Note that profiles provide a default setting for CHOST; depending on the situation, it may be necessary to override it in /etc/portage/make.conf or remove an override in /etc/portage/make.conf. In any case, the important point is that the effective value changes.

Please note that if planning to use another value of CHOST than the profile default, the CHOST_${ABI} variable may need updating as well. It is possible to query the value of this variable of the currently set profile with the portageq tool:

user $portageq envvar ABI

n32

user $portageq envvar CHOST_n32

mips64-unknown-linux-gnuabin32

If this value is equal to CHOST, it's good. Otherwise, override it as well, e.g.:

ФАЙЛ /etc/portage/make.conf

CHOST_n32="mips64-unknown-linux-gnuabin32"

Сборка пакетов

Важно
It is generally a good idea to rebuild the packages to the same versions as before the CHOST switch, i.e. avoiding combining upgrades with it. If multiple slots are installed, either uninstall extraneous slots or rebuild all of them. If that is not possible, please upgrade the packages first (with old CHOST). While it may not be impossible to do so, it is hard to predict which potential problems may arise and almost impossible to document them in this guide.

Важно
If the CHOST switch takes place together with other changes, e.g. in the course of a profile upgrade, please read the documentation there as well to make sure the different steps do not interfere.

Rebuild the following packages in this order:

root #emerge --ask --oneshot sys-devel/binutils

Заметка
Перед компиляцией gcc может понадобиться запустить binutils-config.

root #emerge --ask --oneshot sys-devel/gcc

root #emerge --ask --oneshot sys-libs/glibc

For glibc based systems:

root #emerge --ask --oneshot sys-libs/glibc

For musl based systems:

root #emerge --ask --oneshot sys-libs/musl

Проверка работоспособности

Пришло время проверить, что настройки gcc-config и binutils-config в порядке, и что нет никакого «мусора» в /etc/env.d/.

Вывод gcc-config и binutils-config должен выглядеть следующим образом:

Заметка
Вывод скорее всего будет отличаться в зависимости от версии gcc и настроек CHOST. В примере ниже используется gcc 12 на mips.

root #gcc-config -l

 [1] mips64-unknown-linux-gnuabin32-12 *

root #gcc-config -c

mips64-unknown-linux-gnuabin32-12

root #binutils-config -l

 [1] mips64-unknown-linux-gnuabin32-2.39 *
# binutils-config -c
mips64-unknown-linux-gnuabin32-2.39

Теперь проверим, остались ли ссылки на старую переменную CHOST в /etc/env.d/:

root #cd /etc/env.d/

root #grep linux-gnu *

04gcc-mips64-unknown-linux-gnu:MANPATH="/usr/share/gcc-data/mips64-unknown-linux-gnu/12/man"
04gcc-mips64-unknown-linux-gnu:INFOPATH="/usr/share/gcc-data/mips64-unknown-linux-gnu/12/info"
04gcc-mips64-unknown-linux-gnuabin32:MANPATH="/usr/share/gcc-data/mips64-unknown-linux-gnuabin32/12/man"
04gcc-mips64-unknown-linux-gnuabin32:INFOPATH="/usr/share/gcc-data/mips64-unknown-linux-gnuabin32/12/info"
05binutils:MANPATH=/usr/share/binutils-data/mips64-unknown-linux-gnuabin32/2.39/man
05binutils:INFOPATH=/usr/share/binutils-data/mips64-unknown-linux-gnuabin32/2.39/info

Here, binutils is fine - there is one file, and it only contains references to the new CHOST. For gcc, there is a file for both the new and the old CHOST value, so delete the old stale one:

root #rm 04gcc-mips64-unknown-linux-gnu

Аналогично поступим с файлами binutils: если существует больше одного файла, смотрите, какой является устаревшим и удалите его. Далее, проверьте содержимое /etc/env.d/binutils/.

root #cd /etc/env.d/binutils/

root #ls -l

total 12
-rw-r--r-- 1 root root  13 Dec  9 22:16 config-mips64-unknown-linux-gnu
-rw-r--r-- 1 root root  13 Dec 31 17:00 config-mips64-unknown-linux-gnuabin32
-rw-r--r-- 1 root root 117 Dec 31 16:59 mips64-unknown-linux-gnuabin32-2.39

root #cat config-mips64-unknown-linux-gnuabin32

CURRENT=2.39

root #cat mips64-unknown-linux-gnuabin32-2.39

TARGET="mips64-unknown-linux-gnuabin32"
VER="2.39"
LIBPATH="/usr/lib32/binutils/mips64-unknown-linux-gnuabin32/2.39"

Всё хорошо, эти два файла и должны быть тут. Пришло время заглянуть в каталог gcc/.

root #rm config-mips64-unknown-linux-gnu

Time to move on to the gcc/ directory.

root #cd /etc/env.d/gcc

# ls -l
total 12
-rw-r--r-- 1 root root  36 Dec 30 11:31 config-mips64-unknown-linux-gnu
-rw-r--r-- 1 root root  42 Dec 31 23:54 config-mips64-unknown-linux-gnuabin32
-rw-r--r-- 1 root root 353 Dec 31 23:52 mips64-unknown-linux-gnuabin32-12

root #cat config-mips64-unknown-linux-gnuabin32

CURRENT=mips64-unknown-linux-gnuabin32-12

root #cat config-mips64-unknown-linux-gnu

CURRENT=mips64-unknown-linux-gnu-12

root #cat mips64-unknown-linux-gnuabin32-12

GCC_PATH="/usr/mips64-unknown-linux-gnuabin32/gcc-bin/12"
LDPATH="/usr/lib/gcc/mips64-unknown-linux-gnuabin32/12"
MANPATH="/usr/share/gcc-data/mips64-unknown-linux-gnuabin32/12/man"
INFOPATH="/usr/share/gcc-data/mips64-unknown-linux-gnuabin32/12/info"
STDCXX_INCDIR="g++-v12"
CTARGET="mips64-unknown-linux-gnuabin32"
GCC_SPECS=""
MULTIOSDIRS="../lib32"

Файлы config-mips64-unknown-linux-gnuabin32 и mips64-unknown-linux-gnuabin32-12 в порядке, а config-mips64-unknown-linux-gnu — «мусор», который нужно удалить.

Заметка
Опять же файл, содержащий ссылку на старую версию gcc, может иметь другое имя (например, config-i686-pc-linux-gnu) даже в случае, когда система меняется (в данном случае) на CHOST i686. Важно различать файлы по содержимому, а не только по имени.

root #rm config-mips64-unknown-linux-gnu

Теперь запустите следующую команду для обновления переменных среды:

root #env-update && source /etc/profile

Далее проверим, что всё в порядке:

Завершение изменений

Теперь нужно пересобрать sys-devel/libtool:

root #emerge --ask --oneshot libtool

Теперь можно пересобрать все пакеты:

root #emerge --ask --emptytree @world

In theory, it should not be necessary to do so, but it cannot be 100% guaranteed that this is actually the case. Alternatively, it is possible to manually rebuild all the known problematic packages:

• multilib packages using CHOST prefixing or header wrapping,
• Perl, Python and other tools that store configured compiler path.

root #emerge --ask --oneshot /usr/bin/mips64-unknown-linux-gnu-* /usr/include/mips64-unknown-linux-gnu /usr/lib/llvm/*/bin/mips64-unknown-linux-gnu-* dev-lang/perl dev-lang/python

Note that paths that do not apply to the current system may need removing from the above invocation.

Если обнаружили пакет, который также требует пересборки, то, пожалуйста, сообщите нам на странице обсуждения этого руководства.

Распространённые проблемы

Not so many anymore. Usually this just works, as long as no really exotic change is done. Make sure to not combine the CHOST change with other steps though. Some of the notes below are really old...

При обновлении с gcc 3.3 до 4.1 одновременно с изменением переменной CHOST (и всё же, пожалуйста, не делайте этого), пара пользователей сообщала о «битых» пакетах, которые нуждаются в пересборке, таких как sys-apps/groff и mail-mta/courier:

КОД Сообщение об ошибке

error while loading shared libraries: libstdc++.so.5: cannot open shared object file: No such file or directory

Это происходит, поскольку процессе обновления CHOST не соответствует CTARGET, из-за чего компилятор считает что в системе используется кросс-компиляция. Как следствие, LDPATH не вносится в ld.so.conf, что приводит к ошибке.

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

В некоторый редких случаях, могут также «сломаться» старые версии python. Это можно исправить, добавив /usr/lib/gcc-lib/i386-pc-linux-gnu/3.3.6 (измените в соответствии со старым CHOST и версией gcc) в /etc/ld.so.conf, запустите ldconfig и, затем, emerge libstdc++-v3. Однако, как можно увидеть, этих проблем определённо стоит избегать — не изменяйте CHOST и версию gcc одновременно.

Обратная связь

На этом, должно быть, всё. Отзывы (как в случае, если это сработало, так и в случае неудачи или неожиданных проблем) приветствуются: пожалуйста, используйте страницу обсуждения или сообщите в этом треде форума. Многое в этом руководстве сделано участником vapier, спасибо за помощь!

---

This page is based on a document formerly found on our main website gentoo.org.
The following people contributed to the original document: Wernfried Haas, Mike Frysinger (vapier) , Chris White
They are listed here because wiki history does not allow for any external attribution. If you edit the wiki article, please do not add yourself here; your contributions are recorded on each article's associated history page.