Gentoo Logo

Cambiare la variabile CHOST

Indice:

1.  Introduzione

Cambiare il CHOST è una grossa problematica che può seriamente compromettere il proprio sistema - allora perché c'è una guida a riguardo?

Ci sono certe situazioni nelle quali cambiare CHOST è inevitabile, ad esempio volendo aggiornare a glibc 2.4, che supporta solamente nptl, e avendo CHOST impostato a i386, che rende impossibile l'utilizzo di nptl. In questo caso le scelte possibili non sono molte, ed una di queste è proprio cambiare CHOST.

Anche seguendo queste istruzioni, potrebbero comunque insorgere dei problemi, per cui assicurarsi di leggerle ed eseguirle molto attentamente. In questo esempio la variabile CHOST verrà cambiata da i386 a i686, se si effettua un cambiamento diverso modificare di conseguenza i comandi.

2.  Cambiare la variabile CHOST

Compilare i pacchetti

Come prima cosa, modificare il file /etc/portage/make.conf e cambiare il valore di CHOST in base alla proprie esigenze. Quindi ricompilare i seguenti pacchetti in questo preciso ordine:

Codice 2.1: Ricompilare gli strumenti di sistema essenziali

# emerge -av1 binutils gcc glibc

Importante: Si deve essere consapevoli del fatto che aggiornamenti maggiori di gcc contemporanei al cambiamento di CHOST (es. partendo da gcc 3.3, CHOST i386 e migrando a gcc 4.1, CHOST i686) possono introdurre gravi effetti collaterali. Sebbene non sia impossibile eseguire questo passaggio, è difficile prevedere e documentare i potenziali problemi che potrebbero insorgere. Di conseguenza, si prega di fare un passaggio alla volta, per esempio aggiornando prima gcc seguendo la guida all'aggiornamento di GCC e successivamente cambiando il proprio CHOST. Se si ha un sistema con CHOST=i386, durante l'aggiornamento di gcc bisogna mascherare glibc 2.4 (o versioni successive), in quanto non utilizzabile su i386, e smascherarlo dopo l'aggiornamento.

Verifiche globali di funzionamento

Ora bisogna assicurarsi che le impostazioni di gcc-config e binutils-config siano corrette e non ci siano degli "scarti" di configurazione in /etc/env.d.

L'output di gcc-config e binutils-config dovrebbe apparire più o meno così (potrebbero differire in base alla propria versione di gcc e il proprio chost, qui rispettivamente gcc 4.1.1. e i686):

Codice 2.2: Verificare la correttezza della configurazione

# gcc-config -l
 [1] i686-pc-linux-gnu-4.1.1 *
# gcc-config -c
i686-pc-linux-gnu-4.1.1

# binutils-config -l
 [1] i686-pc-linux-gnu-2.16.1 *
# binutils-config -c
i686-pc-linux-gnu-2.16.1

Verificare poi che non ci sia nessun riferimento al vecchio CHOST in /etc/env.d/:

Codice 2.3: Controllare i riferimenti al vecchio CHOST

# cd /etc/env.d/
# grep 386 *
05gcc-i386-pc-linux-gnu:PATH="/usr/i386-pc-linux-gnu/gcc-bin/4.1.1"
05gcc-i386-pc-linux-gnu:ROOTPATH="/usr/i386-pc-linux-gnu/gcc-bin/4.1.1"

Nota: Ciò non dovrebbe accadere nella propria situazione, ma in questo caso 05gcc-i386-pc-linux-gnu contiene un riferimento al vecchio CHOST. Le cose potrebbero risultare differenti nel proprio sistema in base a/da quale CHOST si sta migrando, o perfino essere apposto. Il nome potrebbe anche essere 05gcc-tuo_nuovo_CHOST-pc-linux-gnu.

Prima di eliminare il file, verificare gli altri aventi il CHOST aggiornato:

Codice 2.4: Verificare i file con il CHOST aggiornato

# grep 686 *
05binutils:MANPATH=/usr/share/binutils-data/i686-pc-linux-gnu/2.16.1/man
05binutils:INFOPATH=/usr/share/binutils-data/i686-pc-linux-gnu/2.16.1/info
05binutils:LDPATH=/usr/i686-pc-linux-gnu/lib
05gcc:PATH="/usr/i686-pc-linux-gnu/gcc-bin/4.1.1"
05gcc:ROOTPATH="/usr/i686-pc-linux-gnu/gcc-bin/4.1.1"
05gcc:MANPATH="/usr/share/gcc-data/i686-pc-linux-gnu/4.1.1/man"
05gcc:INFOPATH="/usr/share/gcc-data/i686-pc-linux-gnu/4.1.1/info"
05gcc:LDPATH="/usr/lib/gcc/i686-pc-linux-gnu/4.1.1"

Sembra tutto apposto in quanto dovrebbe esserci solamente un file per gcc in /etc/env.d (05gcc in questo esempio), per cui eliminare il file con i riferimenti sbagliati:

Codice 2.5: Rimuovere i file con i riferimenti errati

# rm 05gcc-i386-pc-linux-gnu

Lo stesso ragionameno si applica a binutils - se c'è un file di troppo, identificare quello vecchio e cancellarlo. Successivamente controllare /etc/env.d/binutils/

Codice 2.6: Verificare la correttezza di binutils

# cd /etc/env.d/binutils/
# ls -la
total 8
-rw-r--r-- 1 root root  15 Sep  3 13:48 config-i686-pc-linux-gnu
-rw-r--r-- 1 root root 126 Sep  3 13:48 i686-pc-linux-gnu-2.16.1

# cat config-i686-pc-linux-gnu
CURRENT=2.16.1
# cat i686-pc-linux-gnu-2.16.1
TARGET="i686-pc-linux-gnu"
VER="2.16.1"
LIBPATH="/usr/lib/binutils/i686-pc-linux-gnu/2.16.1"
FAKE_TARGETS="i686-pc-linux-gnu"

Questa configurazione è corretta, questi due file sono effettivamente al loro posto. Ora spostarsi nella directory di gcc.

Codice 2.7: Verificare la correttezza di gcc

# cd /etc/env.d/gcc
# ls -la
total 12
-rw-r--r-- 1 root root  32 Sep  3 16:43 config
-rw-r--r-- 1 root root  32 Aug  3 14:25 config-i386-pc-linux-gnu
-rw-r--r-- 1 root root 292 Sep  3 16:43 i686-pc-linux-gnu-4.1.1

# cat config
CURRENT=i686-pc-linux-gnu-4.1.1

# cat config-i386-pc-linux-gnu
CURRENT=i386-pc-linux-gnu-4.1.1

# cat i686-pc-linux-gnu-4.1.1
PATH="/usr/i686-pc-linux-gnu/gcc-bin/4.1.1"
ROOTPATH="/usr/i686-pc-linux-gnu/gcc-bin/4.1.1"
LDPATH="/usr/lib/gcc/i686-pc-linux-gnu/4.1.1"
GCCBITS="32"
MANPATH="/usr/share/gcc-data/i686-pc-linux-gnu/4.1.1/man"
INFOPATH="/usr/share/gcc-data/i686-pc-linux-gnu/4.1.1/info"
STDCXX_INCDIR="g++-v4"

config e i686-pc-linux-gnu-4.1.1 sono corretti, ma config-i386-pc-linux-gnu è un'altro "rimasuglio" di configurazione da rimuovere.

Nota: Si ricorda nuovamente che il nome del file contenente i riferimenti ad una vecchia versione di gcc potrebbe differire, ad esempio potrebbe chiamarsi config-i686-pc-linux-gnu anche se si sta migrando a i686. È importante identificare il file dal suo contenuto, non solo dal nome.

Codice 2.8: Rimuovere il file di configurazione di gcc errato

# rm config-i386-pc-linux-gnu

A questo punto eseguire i seguenti comandi per aggiornare il proprio ambiente:

Codice 2.9: Aggiornare l'ambiente

# env-update && source /etc/profile

Verificare che tutto sia stato corretto:

Codice 2.10: Verificare che i riferimenti al vecchio CHOST siano stati rimossi

# grep -r 386 /etc/env.d/

Se viene trovato nuovamente qualcosa , probabilmente qualche file dev'essere sfuggito: è importante rintracciarli e rimuoverli prima di procedere oltre.

Completare la Modifica

È necessario ri-emergere libtool ed eseguire /usr/share/gcc-data/$CHOST/<gcc-version>/fix_libtool_files.sh. Assicurarsi di usare la corretta versione di gcc: (quella attuale, qui 4.1.1., e la vecchia architettura, qui i386). Sostituire $CHOST con il proprio nuovo CHOST, e <gcc-version> con la propria versione di gcc. In questo esempio si suppone di avere un CHOST i686.

Codice 2.11: Assicurare l'integrità delle librerie

# emerge -av1 libtool
# /usr/share/gcc-data/i686-pc-linux-gnu/4.1.1/fix_libtool_files.sh 4.1.1 --oldarch i386-pc-linux-gnu

Se lo si desidera, ricompilare tutti i pacchetti:

Codice 2.12: Ricompilare world

# emerge -e world

Teoricamente questa operazione non è necessaria, ma non lo si può garantire al 100%. Anche se world non viene ricompilato interamente, bisogna in ogni caso ricompilare almeno qualche pacchetto (es. python):

Codice 2.13: Reinstallare python

# emerge -av1 python

Tutti i pacchetti basati su perl vengono installati nella directory CHOST perciò necessitano di una re-installazione. Nel caso non si abbia installato qfile, bisogna prima installare app-portage/portage-utils.

Codice 2.14: Reinstallare i pacchetti perl

# emerge -av portage-utils
# emerge -av1 `qfile /usr/lib/perl* -Cq | sort -u`

Se vengono individuati altri pacchetti che necessitano della ricompilazione, si prega di comunicarlo all'autore di questo documento.

Problemi principali

Se si aggiorna da gcc 3.3 a 4.1 in concomitanza con il cambio di CHOST (si prega di non farlo in ogni caso), un paio di utenti hanno riportato la corruzione di alcuni pacchetti che necessitano di una ricompilazione, come groff e courier:

Codice 2.15: Messaggio d'errore

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

Questo avviene perché durante l'aggiornamento CHOST non combacia esattamente con CTARGET e il compilatore assume che si sia effettuando una cross-compilazione. Di conseguenza, LDPATH non viene inserito in ld.so.conf, generando l'errore precedentemente elencato.

Leggere la guida all'aggiornamento di GCC per informazioni sui pacchetti da ricompilare dopo un aggiornamento di gcc.

In qualche caso raro, potrebbero anche corrompersi le vecchie versioni di python. Si può correggere il problema aggiungendo /usr/lib/gcc-lib/i386-pc-linux-gnu/3.3.6 (modificare la voce in base al proprio vecchio chost e alla propria versione di gcc, di conseguenza) a /etc/ld.so.conf, eseguire ldconfig e poi emerge libstdc++-v3. Tuttavia, bisognerebbe evitare di incorrere in questo problema - non effettuare insieme il cambio di CHOST e l'aggiornamento di versione di gcc.

Commenti

Qualsiasi commento riguardante questa guida e le sue istruzioni (sia che funzionino, sia che non funzionino o che si incontrino altri problemi) è ben accetto, si prega di spedire un e-mail a Wernfried Haas o scrivere su questa discussione del forum. Gran parte di questa guida proviene da vapier, grazie per il suo aiuto!



Stampa

Aggiornato il 24 luglio 2012

La versione originale di questo documento non è più mantenuta

Oggetto: Questo documento spiega come cambiare la variabile CHOST di un sistema esistente.

Wernfried Haas
Autore

Mike Frysinger
Revisione

Chris White
Redazione

Davide Cendron
Traduzione

Donate to support our development efforts.

Copyright 2001-2014 Gentoo Foundation, Inc. Questions, Comments? Contact us.