# [SOLVED] cambiare CHOST durante la vita di un sistema

## Peach

Salve gente, proprio oggi quando mi sono deciso di installare usermode linux ho notato che lo stage 3 che ho installato nella macchina virtuale aveva nel make.conf CHOST settato a i686... come me ne sono accorto?

beh dopo che mi sono detto: aggiorno gcc dandogli il package della mia macchina host... il problema è che nella mia macchina host ho CHOST settato a i386... bel casino... ho dovuto cancellare la root_fs della macchina virtuale perchè stava iniziando a diventare più stressante correggere il problema che altro (in altre parole emerge non partiva).

ora mi domando... se volessi cambiare sulla mia macchina il CHOST cosa dovrei fare per evitare di sputtanare tutto e ricompilare tutto a modo in maniera sicura?

ma soprattutto: conviene???

----------

## Luca89

Devi utilizzare il tool fix_libtool_files.sh per sistemare tutto:

```
Usage: fix_libtool_files.sh <old-gcc-version> [--oldarch <old-CHOST>]

    Where <old-gcc-version> is the version number of the

    previous gcc version.  For example, if you updated to

    gcc-3.2.1, and you had gcc-3.2 installed, run:

      # fix_libtool_files.sh 3.2

    If you updated to gcc-3.2.3, and the old CHOST was i586-pc-linux-gnu

    but you now have CHOST as i686-pc-linux-gnu, run:

      # fix_libtool_files.sh 3.2 --oldarch i586-pc-linux-gnu

    Note that if only the CHOST and not the version changed, you can run

    it with the current version and the '--oldarch <old-CHOST>' arguments,

    and it will do the expected:

      # fix_libtool_files.sh `gcc -dumpversion` --oldarch i586-pc-linux-gnu

```

 :Wink: 

----------

## Peach

si ma nn ha funzionato come doveva... continuava a lamentarsi della mancanza di libstdc++.so.5

quindi ho brasato tutto... problema nessuno.. il pacco è aspettare che finisca l'emerge sync che è eterno su una macchina nuova, anche se virtuale

----------

## .:chrome:.

 *Luca89 wrote:*   

> Devi utilizzare il tool fix_libtool_files.sh per sistemare

 

 :Question:   :Question:   :Question: 

cos'è questa storia che tutti si risolve con quello?

è un tool non documentato che viene usato DALL'EBUILD durante l'aggiornamento del compilatore. leggendo sul forum sembra che possa rimediare anche alla cervicale...

emerge -e system

----------

## Ic3M4n

si, con libtool non fai altro che modificare i path per le librerie... 

se vuoi modificare CHOST devi ricompilarti il sistema da zero. in quanto tutti i tuoi programmi sono stati compilati per i386. se li vuoi per i686 devi prima ricompilare il compilatore e poi dare un emerge -e world. però non credo che il miglioramento prestazionale che "potresti" ottenere valga una completa ricompilazione. 

...asp. ma hai appena decompresso lo stage? allora non ci metti tantissimo, penso.

----------

## .:chrome:.

 *Ic3M4n wrote:*   

> devi prima ricompilare il compilatore

 

non è necessario. figurati se un compilatore non può produrre output per diverse architetture  :Wink:  non siamo in Microsoft

----------

## Peach

 *Ic3M4n wrote:*   

> si, con libtool non fai altro che modificare i path per le librerie... 
> 
> se vuoi modificare CHOST devi ricompilarti il sistema da zero. in quanto tutti i tuoi programmi sono stati compilati per i386. se li vuoi per i686 devi prima ricompilare il compilatore e poi dare un emerge -e world. però non credo che il miglioramento prestazionale che "potresti" ottenere valga una completa ricompilazione. 
> 
> ...asp. ma hai appena decompresso lo stage? allora non ci metti tantissimo, penso.

 

quindi confermi che prestazionalmente parlando è inutile?

questo servirebbe per poter passare packages dall'host al guest senza dover ricompilare da zero... mi sa che quindi faccio prima a portare a i386 il guest e lasciare l'host così...

----------

## .:chrome:.

 *Peach wrote:*   

> quindi confermi che prestazionalmente parlando è inutile?
> 
> questo servirebbe per poter passare packages dall'host al guest senza dover ricompilare da zero... mi sa che quindi faccio prima a portare a i386 il guest e lasciare l'host così...

 

no. nessuno ha detto questo.

secondo me (ma è un'idea mia) è inutile, dal punto di vista prestazionale, diventare matti con le flag USE. ma settare correttamente il processore non può di certo far male, anzi...

----------

## Peach

quindi in realtà sarebbe più corretto ricompilarmi la mia macchina... hmmm... magari appena ho una rete distcc per poterlo fare. 

Probabilmente installando un package con CHOST diversa si rompe per forza qualcosa; non necessariamente se si cambia la CHOST flag e si ricompila normalmente -ad es- gcc.

O mi sono perso qualcosa?

----------

## .:chrome:.

non credo proprio, anche se non ho mai provato.

un conto è compilare software per architetture diverse, lì è ovvio che non funziona, ma software compilati per versioni diverse della stessa architettura non vedo come potrebbero darsi fastidio. sarebbe come dire che un pentium non può eseguire codice i386: è assurdo, perché le due piattaforme sono compatibili.

oltretutto CHOST non setta nemmeno l'architettura target, se non sbaglio, ma sceglie il profilo del compilatore, quindi si tratterebbe solo di avere un compilatore ottimizzato o meno, che produce comunque output corretti

----------

## Ic3M4n

@k.gothmog: quando dicevo che il vantaggio prestazionale non valeva la ricompilazione intendevo che quando hai tutto un sistema installato il ricompilare tutto potrebbe non valere la "spesa" di tempo per il guadagno prestazionale. poi dipende... onestamente non ho mai fatto paragoni, però molte distro compilano ancora per 386, e solo alcune tipo suse sono passate a 586, quindi non credo che il divario tra le due sia cos' ampio. 

inoltre come hai detto tu nell'ultimo post in effetti avere tal parametro impostato su 386 non dovrebbe provocare un crash del sistema, potrebbe essere più facilmente una corruzione dello stage scaricato. o cose del genere cmq.

----------

## randomaze

 *Peach wrote:*   

> quindi in realtà sarebbe più corretto ricompilarmi la mia macchina... hmmm... magari appena ho una rete distcc per poterlo fare. 
> 
> Probabilmente installando un package con CHOST diversa si rompe per forza qualcosa; non necessariamente se si cambia la CHOST flag e si ricompila normalmente -ad es- gcc.
> 
> O mi sono perso qualcosa?

 

Quello che sicuramente cambia é la dir:

```
/usr/lib/gcc-lib/i686-pc-linux-gnu/
```

sembra una cosa stupida ma in realtá la libreria che non ti trova (libstdc++.so.5) presumibilmente si trova in:

```
/usr/lib/gcc-lib/i386-pc-linux-gnu/
```

(oppure é in i686 e non in i386)

hai provato a cercarla con find e/o locate?

N.B. Se l'errore é questo ricorda che  fix_libtool_files.sh va usato con il parametro --oldarch.

----------

## Peach

 *randomaze wrote:*   

>  *Peach wrote:*   quindi in realtà sarebbe più corretto ricompilarmi la mia macchina... hmmm... magari appena ho una rete distcc per poterlo fare. 
> 
> Probabilmente installando un package con CHOST diversa si rompe per forza qualcosa; non necessariamente se si cambia la CHOST flag e si ricompila normalmente -ad es- gcc.
> 
> O mi sono perso qualcosa? 
> ...

 

si infatti.. era in i686, quando il package aveva installato tutto in i386... fix_libtool_files.sh nn ha funzionato nemmeno passandogli --oldarch... o meglio... lui sembra funzionare, mi aveva anche segnalato il fix di un file, ma alla fine emerge continuava a lamentarsi (python chiamato da emerge in questo caso).

l'unica cosa che mi è chiara è che il package preso e sbattuto lì se aveva CHOST diverso spaccava tutto

ma nn mi è ancora chiaro se cambio CHOST e compilo regolarmente -tipo gcc- sono passibile di problemi del genere...

----------

## makoomba

dopo un cambio di CHOST, ricompilerei tutto il sistema.

in particolare, rifarei il bootstrap

```
emerge glibc binutils gcc && emerge glibc binutils gcc
```

e almeno 

```
emerge -e world
```

----------

## .:chrome:.

 *Ic3M4n wrote:*   

> molte distro compilano ancora per 386, e solo alcune tipo suse sono passate a 586, quindi non credo che il divario tra le due sia cos' ampio.

 

quello viene fatto solo per garantire la compatibilità architetturale.

 *makoomba wrote:*   

> dopo un cambio di CHOST, ricompilerei tutto il sistema

 

ribadisco che CHOST setta il compilatore, e non ha nessuna influenza sul codice compilato. faresti un'operazione inutile.

sarebbe cosa diversa se dovessi cambiare CFLAGS, ma anche in quel caso è più che sufficiente un emerge -e glibc, e nulla di più, dato che è solo dalle glibc che dipende tutto il sistema (e le sue prestazioni)

----------

## makoomba

 *k.gothmog wrote:*   

> ribadisco che CHOST setta il compilatore, e non ha nessuna influenza sul codice compilato. faresti un'operazione inutile

 

 *handbook wrote:*   

> Warning: Although it might be tempting for non-stage1 users, they should not change the CHOST setting in make.conf. Doing so might render their system unusable. Again: only change this variable if you use a stage1 installation.

 

ti consiglio di cercare sul forum internazionale gli interventi di BobP e rac sull'argomento

----------

## Peach

 *handbook wrote:*   

> Warning: Although it might be tempting for non-stage1 users, they should not change the CHOST setting in make.conf. Doing so might render their system unusable. Again: only change this variable if you use a stage1 installation.

 

eh, ho fatto io la cazzata a non modificarlo quando ho fatto stage 1 a suo tempo  :Twisted Evil: 

----------

## .:chrome:.

@makoomba: scusa un attimo... a me hanno insegnato a ragionare con la mia testa.

hai guardato a cosa serve CHOST? a giudicare da quello che scrivi parrebbe proprio di no

 *make.conf wrote:*   

> # Host Setting
> 
> # ============
> 
> #
> ...

 

ora... andiamo a vedere cosa è quella roba:

```
chrome@morgoth ~ $ which i686-pc-linux-gnu-gcc

/usr/bin/i686-pc-linux-gnu-gcc

chrome@morgoth ~ $ ls /usr/bin/*gnu-gcc

/usr/bin/i386-pc-linux-gnu-gcc*  /usr/bin/i686-pc-linux-gnu-gcc*
```

si tratta degli eseguibili di gcc. niente più.

se ha un'architettura i686 è liberissimo si cambiare la dichiarazione come meglio crede (non è così immediato il viceversa). per la cronaca... quel quote l'ho preso dal mio computer di casa, realizzato a partire da stage3 e con successivo emerge -e glibc

penso che ragionare con la propria testa non sia male, di tanto in tanto.

----------

## makoomba

ma davvero ?

vuoi dare, sul tuo sistema

```
i386-pc-linux-gnu-gcc -v

ls -l /usr/lib/gcc-lib/i386-pc-linux-gnu

```

e postarmi l'output, gentilmente ?

beh, non so da te, ma sul mio sistema ho compilatore e librerie solo per i686.

cambiando CHOST, non posso compilare assolutamente nulla perchè, di fatto, non è presente alcun compilatore per la nuova architettura.

e non intendo solo l'eseguibile gcc ma anche, e soprattutto, tutte le librerie in /usr/lib/ggc-lib alle quali linkano i binari.

se si vuole cambiare CHOST, il primo passo è ricompilare gcc per la nuova architettura.

Le librerie i386 sono diverse da quelle generate per i686, avere un sistema in cui vengono utilizzate entrambe può causare problemi e malfunzionamenti difficilmente identificabili.

Per questo, nell'handbook, viene fortemente sconsigliata la modifica di CHOST a meno che si parta da uno stage1.

ora, i post che ti citavo sono relativi a ben note discussioni riguardati la "consistenza" del toolchain e quanto questa sia importante in gentoo (metadistro basata interamente sulla compilazione dei sorgenti )

in ultimo, una considerazione sulla forma.

il fatto che taluni utenti del forum possano apprezzare il "tono" di alcuni dei tuoi interventi, non implica che lo stesso valga per altri.

io sono fra gli altri, tienilo a mente.

----------

## .:chrome:.

 *makoomba wrote:*   

> ma davvero ?
> 
> vuoi dare, sul tuo sistema
> 
> ```
> ...

 

ho scritto...

 *k.gothmog wrote:*   

> se ha un'architettura i686 è liberissimo si cambiare la dichiarazione come meglio crede (non è così immediato il viceversa).

 

se non fosse possibile il passaggio i386 -> i686 non funzionerebbe nemmeno nessuna delle distribuzioni pacchettizzate su macchine superiori all'i486

----------

## makoomba

 *k.gothmog wrote:*   

> se non fosse possibile il passaggio i386 -> i686 non funzionerebbe nemmeno nessuna delle distribuzioni pacchettizzate su macchine superiori all'i486

 

Questo non è un problema, il gcc sulle distro binarie è sempre compilato per la minima architettura supportata.

prendi i binari CentOS (ma vale per qualsiasi distro RH like): CHOST=i386-redhat-linux, march=i386, mcpu=i686 e funzionano su qualsiasi x86.

Il problema sta nel cambiare CHOST "live" sulla stessa macchina.

Entrambe le architetture funzionano correttamente, ma lo switch non si riduce alla mera modifica del make.conf

----------

## .:chrome:.

 *makoomba wrote:*   

> Questo non è un problema, il gcc sulle distro binarie è sempre compilato per la minima architettura supportata.
> 
> prendi i binari CentOS (ma vale per qualsiasi distro RH like): CHOST=i386-redhat-linux, march=i386, mcpu=i686 e funzionano su qualsiasi x86.

 

esempio secondo me sbagliato. c'è una certa divergenza strutturale tra Gentoo (di cui qui si parla) e RedHat

 *makoomba wrote:*   

> Il problema sta nel cambiare CHOST "live" sulla stessa macchina.
> 
> Entrambe le architetture funzionano correttamente, ma lo switch non si riduce alla mera modifica del make.conf

 

ma io non ho mai sostenuto questo. se guardi qualche post indietro puoi leggere quello che io avevo suggerito

----------

## makoomba

 *k.gothmog wrote:*   

> esempio secondo me sbagliato. c'è una certa divergenza strutturale tra Gentoo (di cui qui si parla) e RedHat

 

allora non ho capito cosa intendevi con "distro pacchettizzate"

----------

## .:chrome:.

 *makoomba wrote:*   

>  *k.gothmog wrote:*   esempio secondo me sbagliato. c'è una certa divergenza strutturale tra Gentoo (di cui qui si parla) e RedHat 
> 
> allora non ho capito cosa intendevi con "distro pacchettizzate"

 

invece hai capito... però io avevo fatto quel riferimento alludendo ad un aspetto diverso da quello che tu hai citato: CHOST è un discorso valido solo su Gentoo e derivate. tutto questo discorso non esiste sulle altre

----------

## Benve

Salve gente, premesso che secondo me si fa prima a reinstallare.

Ho una domanda:

Se uso un pacchetto compilato con i386 su un sistema con tutto compilato per i686 dovrebbe tutto funzionare no ?

----------

## Ic3M4n

si. dovrebbe funzionare. 

non funziona il contrario. su un 386 avere un modulo 686. sempre che lo trovi un 386 in giro... beh diciamo anche un 586 dai.

----------

## Peach

 *Benve wrote:*   

> Salve gente, premesso che secondo me si fa prima a reinstallare.
> 
> Ho una domanda:
> 
> Se uso un pacchetto compilato con i386 su un sistema con tutto compilato per i686 dovrebbe tutto funzionare no ?

 

il che significa che se la mia macchina è correntemente compilata i386, e ricompilo gcc (giusto per dire il primo pacchetto) con CHOST settata a i686, gcc dovrebbe continuare a funzionare permettendomi di ricompilare il resto del sistema, o rischio che molte altre cose si spacchino? i*86-pc-linux-gnu è una cosa sola ed esclusiva di gcc?

----------

## Benve

Come soluzione pratica io farei così:

1. spulcio il world e faccio pacchetti binari di tutto con quickpkg

2. bel backup sia del sistema intero sia dei binari appena creati

3. reinstallo da stage3 con i686, poi uso i binari creati per riavere in poco tempo il mio sistema. 

Ovviamente senza usare i binari di cose come il gcc o le glibc altrimenti torno al problema di prima.

Quali pacchetti secondo voi non andrebbero usati oltre a gcc e glibc ?

----------

## Benve

 *Peach wrote:*   

> 
> 
> il che significa che se la mia macchina è correntemente compilata i386, e ricompilo gcc (giusto per dire il primo pacchetto) con CHOST settata a i686, gcc dovrebbe continuare a funzionare permettendomi di ricompilare il resto del sistema, o rischio che molte altre cose si spacchino?

 

Secondo me in teoria funziona ma in pratica mi sembra rischioso. Io non lo farei mai  :Smile: 

----------

## Peach

 *Benve wrote:*   

> Come soluzione pratica io farei così:
> 
> 1. spulcio il world e faccio pacchetti binari di tutto con quickpkg
> 
> 2. bel backup sia del sistema intero sia dei binari appena creati
> ...

 

usare quickpkg è inutile: nel caso iniziale evidenziato nel primo post avevo installato gcc i386 nella macchina virtuale che aveva CHOST come i686. da questo deriva immediatamente che portage non funziona più, quindi anche se si backuppa si rischia di non avere niente di usabile.

Dalle successive discussioni, però, si è notato che questo non dovrebbe succedere se si decide di COMPILARE il pacchetto anzichè usandone uno precompilato.

il problema viene da qui in poi.

Tieni presente che cmq il passaggio sarebbe da i386 a i686!

----------

## Benve

 *Peach wrote:*   

> 
> 
> usare quickpkg è inutile: nel caso iniziale evidenziato nel primo post avevo installato gcc i386 nella macchina virtuale che aveva CHOST come i686. da questo deriva immediatamente che portage non funziona più, quindi anche se si backuppa si rischia di non avere niente di usabile.
> 
> 

 

Ma questa è un'atra cosa, quì si è cambiata CHOST, non si è usato un binario compilato per un'architettura inferiore

----------

## Peach

 *Benve wrote:*   

>  *Peach wrote:*   
> 
> usare quickpkg è inutile: nel caso iniziale evidenziato nel primo post avevo installato gcc i386 nella macchina virtuale che aveva CHOST come i686. da questo deriva immediatamente che portage non funziona più, quindi anche se si backuppa si rischia di non avere niente di usabile.
> 
>  
> ...

 

ok, quello che continuo a non capire è se quello che vorrei fare è teoricamente fattibile, e non comporta una rottura del sistema, al di là di qualsiasi e qualsivoglia backup di sistema che ritengo quasi obbligatorio visto che nessuno sembra ci abbia mai provato.

----------

## makoomba

il problema sono le librerie.

```
ldd `which python`

        ....

   libstdc++.so.5 => /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.6/libstdc++.so.5 (0x24dfc000)

   libgcc_s.so.1 => /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.6/libgcc_s.so.1 (0x24f3d000)

        ....

```

se il pacchetto è compilato su CHOST=i386, il binario linka a /usr/lib/gcc-lib/i386-pc-linux-gnu

su un CHOST=i686, quella dir è vuota.

magari si risovle con fix_libtool_files.sh, resta il fatto che il binario è stato originariamente compilato con librerie compilate per un'architettura differente.

----------

## Benve

 *makoomba wrote:*   

> il problema sono le librerie.
> 
> ```
> ldd `which python`
> 
> ...

 

Si, quindi la storia dei binari non funziona. Penso di averci capito qualcosa ora.

----------

## faber

dovrbbe funzionare..

cmq una volta ho trovato un bug nell'ebuild di cdrecord, non mi compilava

ho postato in bugzilla, e durante la discussione un tizio ha fatto: wow, questo assomiglia tantissimo ad un bug che c'era per i386

ho guardato il mio chost e... gia', avevo il chost sbagliato. sistemandolo cdrecord si e' compilato tranquillo

questo per dire: non so se vale la pena dal punto di vista prestazionale, ma a volte ti eviti problemi  :Smile: 

----------

## Peach

aggiorno il thread dicendo: CE L'HO FATTA

 :Wink: 

sarebbe a dire che ho colto l'occasione dell'aggiornamento di gcc alla versione 3.4 per cambiare anche il CHOST a "i686-pc-linux-gnu"

se siete nella necessità di farlo, potrei suggerire di seguire la guida al passaggio a gcc 3.4 che comporta anche la ricompilazione dell'intero system e world.

take care.

----------

## Peach

aggiungo una cosa: ho avuto modo di fare l'upgrade di CHOST su un'altra macchina, sempre in occasione del cambio di gcc,

e devo dire che nulla si incastra se (seguendo la "upgrade gcc guide"), prima di fare lo switch con "gcc-config", si emerge libsdtc++-v3

se nn lo si fa si rischia che python si spacchi e riportare la situazione alla stabilità potrebbe portare via parecchie ore di sonno.

a buon rendere  :Wink: 

----------

## duffimc

 *Peach wrote:*   

> aggiungo una cosa: ho avuto modo di fare l'upgrade di CHOST su un'altra macchina, sempre in occasione del cambio di gcc,
> 
> e devo dire che nulla si incastra se (seguendo la "upgrade gcc guide"), prima di fare lo switch con "gcc-config", si emerge libsdtc++-v3
> 
> se nn lo si fa si rischia che python si spacchi e riportare la situazione alla stabilità potrebbe portare via parecchie ore di sonno.
> ...

 

Quindi ricapitolando i passi da seguire sono questi (seguendo la guida all'aggiornamento di gcc):

1) emerge gcc

2) emerge --oneshot libsdtv++-v3

3) gcc-config i686-pc-linux-gnu-3.4.5

4) source /etc/profile

5) emerge --oneshot libtool

6) emerge -e system

7) emerge -e world

Giustoo??

Domanda...ma il cambio di CHOST in make.conf lo devo fare a mano dopo aver emerso libsdtv++v3???

emerge libsdtv++v3 mi installa le librerire i686 giusto??? O vengono installate quando aggiorno gcc???

Lo dico perchè ho controllato sul mio sistema e in /usr/lib/gcc-lib/ non è presente la directory i686...

Thanks

----------

## Peach

 *duffimc wrote:*   

> Quindi ricapitolando i passi da seguire sono questi (seguendo la guida all'aggiornamento di gcc):
> 
> 1) emerge gcc
> 
> 2) emerge --oneshot libsdtv++-v3
> ...

 

TEORICAMENTE: sappi che non è testata come procedura e potrebbe portarti al blocco totale del sistema, molti mi hanno infatti consigliato di reinstallare completamente piuttosto che rifare questo casino e personalmente ho perso 5 ore di vita (dalle 2 alle 7 di mattina) perché mi si era sputtanato emerge e gcc non compilava più.

Cmq sei libero di divertirti  :Twisted Evil: 

in ogni caso l'emerge di GCC e di LIBSTD++-v3 mi sa che lo devi fare con la nuova CHOST impostata in make.conf, altrimenti è inutile.

una volta emerso gcc, con "gcc-config -l" vedi i profili disponibili, quindi scegli l'ultimo disponibile per i686.

una volta selezionato il profilo gcc con gcc-config, controlla che sia stato effettivamente selezionato con "gcc -v", quindi ricarica profile e lancia emerge incrociando le dita.

se tutto va a buon fine non ti resta che aspettare.

quindi, se segli questa strada... IN BOCCA AL LUPO!

----------

## duffimc

 *Peach wrote:*   

> quindi, se segli questa strada... IN BOCCA AL LUPO!

 

.....CREPII....  :Wink:   :Wink:   :Laughing: 

----------

## darkmanPPT

ho fatto l'aggiornamento del portage e mi sn messo a scaricare gli aggiornameti.

bene... anzi.. male.

emerge -uD world mi fa scaricare anche un aggiornamento di un pacchetto che avevo prima.

jpeg-6b-r7

non va....

nel senso... 

scarica tutto e bene. fa il check solito all'inizio dell'installazione e inizia a compilare finche ad un certo punto

 *Quote:*   

> 
> 
> ......
> 
> /lib/gcc/i386-pc-linux-gnu/3.4.5/crtendS.o /usr/lib/gcc/i386-pc-linux-gnu/3.4.5/../../../crtn.o  -Wl,-soname -Wl,libjpeg.so.62 -o .libs/libjpeg.so.62.0.0
> ...

 

idee su come fare?

anche perchè facendo in questo modo non mi continua con il resto degli aggiornamenti, che, inevitabilemente si accumulano dopo di lui. (si potesse almeno invertire l'ordine)

----------

## ProT-0-TypE

innanzitutto usando l'ozione --skipfirst di emerge salti quel pacchetto e puoi aggiornare gli altri. Poi controlla su bugzilla per vedere se c'è qualche bug già aperto su questo argomento, e se non c'è nel caso aprilo tu. E magari prima prova a risyncare per vedere se hanno già corretto il problema

----------

## darkmanPPT

grazie.

cmq ho già resincato due volte.... ma nulla.

cmq grazie.

non sapevo come fare uno skip.

ciao  :Wink: 

----------

## .:deadhead:.

 *Quote:*   

> i386-pc-linux-gnu-g++: /usr/lib/gcc/i386-pc-linux-gnu/3.4.5/../../../crti.o: No such file or directory
> 
> i386-pc-linux-gnu-g++: /usr/lib/gcc/i386-pc-linux-gnu/3.4.5/crtbeginS.o: No such file or directory
> 
> i386-pc-linux-gnu-g++: /usr/lib/gcc/i386-pc-linux-gnu/3.4.5/crtendS.o: No such file or directory
> ...

 

 :Shocked:   :Shocked:   :Shocked: 

mancan dei pezzi del compilatore? com'è possibile?!

puoi postare cortesemente un 

```
emerge info; gcc-config -l;etc-update
```

mi sa che + che il pacchetto c'è qualcosa che non va sul tuo sistema

----------

## darkmanPPT

ecco quello che mi hai chiesto.

cmq ho risolto il problema.....  :Embarassed: 

è quello che si dice fare una stupidaggine (nn uso altri termini che sarebbero + appropriati)

ho cambiato la variabile CHOST dentro il make.conf ponendo i686.  :Embarassed: 

ho rimesso a posto (i386) ed è tornato come prima. funzia.  :Embarassed: 

cmq mi interesserebbe sapere come fare a mettere CHOST con i686.... le guide che ho trovato qui e là su gentoo non è che mi siano state molto di aiuto.

partono già con l'idea che io dentro /etc/env.d/gcc abbia già i686-pc-linux-gnu-3.4.6...  :Shocked: 

il mio problema è sistemare sta roba qui. dopodichè la guida è anche chiarissima su come fare....

```

Portage 2.0.54-r2 (default-linux/x86/2006.0, gcc-3.4.6, glibc-2.3.6-r3, 2.6.16-gentoo-r74 i686)

=================================================================

System uname: 2.6.16-gentoo-r74 i686 Intel(R) Pentium(R) M processor 2.00GHz

Gentoo Base System version 1.6.14

dev-lang/python:     2.4.2

dev-python/pycrypto: [Not Present]

dev-util/ccache:     [Not Present]

dev-util/confcache:  [Not Present]

sys-apps/sandbox:    1.2.17

sys-devel/autoconf:  2.13, 2.59-r7

sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1

sys-devel/binutils:  2.16.1-r2

sys-devel/libtool:   1.5.22

virtual/os-headers:  2.6.11-r2

ACCEPT_KEYWORDS="x86"

AUTOCLEAN="yes"

CBUILD="i386-pc-linux-gnu"

CFLAGS="-O2 -march=pentium-m -msse2 -pipe"

CHOST="i386-pc-linux-gnu"

CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/lib/X11/xkb /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/"

CONFIG_PROTECT_MASK="/etc/gconf /etc/splash /etc/terminfo /etc/env.d"

CXXFLAGS="-O2 -march=pentium-m -msse2 -pipe"

DISTDIR="/usr/portage/distfiles"

FEATURES="autoconfig distlocks sandbox sfperms strict"

GENTOO_MIRRORS="ftp://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo http://pandemonium.tiscali.de/pub/gentoo/ ftp://pandemonium.tiscali.de/pub/gentoo/ ftp://gd.tuwien.ac.at/opsys/linux/gentoo/ http://ftp.club-internet.fr/pub/mirrors/gentoo ftp://sunsite.informatik.rwth-aachen.de/pub/Linux/gentoo"

LINGUAS="it"

PKGDIR="/usr/portage/packages"

PORTAGE_TMPDIR="/var/tmp"

PORTDIR="/usr/portage"

SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage"

USE="x86 X alsa apache2 apm arts audiofile avi berkdb bitmap-fonts bzip2 cdr cli crypt cups curl dri eds emboss encode esd exif expat fam ffmpeg foomaticdb fortran gdbm gif glut gmp gnome gpm gstreamer gtk gtk2 guile idn imlib innodb ipv6 isdnlog java jpeg junit kde lcms libg++ libwww lua mad mhash mikmod mng motif mp3 mpeg mysql ncurses nls nptl ogg openal opengl oss pam pcre pdflib perl php png pppd python qt quicktime readline reflection samba sdl session slang spell spl ssl tcltk tcpd tetex tiff truetype truetype-fonts type1-fonts udev unicode usb vorbis xine xml xml2 xmms xorg xv zlib linguas_it userland_GNU kernel_linux elibc_glibc"

Unset:  CTARGET, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, MAKEOPTS, PORTAGE_RSYNC_EXTRA_OPTS, PORTAGE_RSYNC_OPTS, PORTDIR_OVERLAY

 [1] i386-pc-linux-gnu-3.4.6 *

 [2] i386-pc-linux-gnu-3.4.6-hardened

 [3] i386-pc-linux-gnu-3.4.6-hardenednopie

 [4] i386-pc-linux-gnu-3.4.6-hardenednopiessp

 [5] i386-pc-linux-gnu-3.4.6-hardenednossp

Scanning Configuration files...

Exiting: Nothing left to do; exiting. :)

```

thnks

----------

## .:chrome:.

hai aggiornato recentemente gcc e hai comcbinato qualche piccolo pasticcio

prova a cambiare il profilo di compilazione con gcc-config e poi ripristinare quello originale.

se così non risolvi fai un emerge libtool -1 e poi ripeti l'operazione sopra

----------

## darkmanPPT

sisi

 :Very Happy:  ho fatto un casino

ma ho già rimesso apposto.

qualcuno mi sa dire come si fa ad impostare i686 sulla variabile CHOST ???

le guide mi dicono 

 *Quote:*   

> 
> 
> # emerge -an gentoolkit
> 
> # emerge -uav gcc
> ...

 

ma  *Quote:*   

> gcc-config i686-pc-linux-gnu-3.4.5

 

non posso farlo perchè NON ho i686-pc-..... in /etc/env.d/gcc/ !!!

come si fa ad averlo??

mi rassegno ad usare i386-pc-....

?  :Question: 

----------

## darkmanPPT

sarebbe da cambiare titolo al topic...

tipo: CHOST="i686-pc-linux-gnu"

----------

## Peach

 *darkmanPPT wrote:*   

> sarebbe da cambiare titolo al topic...
> 
> tipo: CHOST="i686-pc-linux-gnu"

 

una ricerca nel forum ti farà trovare un thread più adeguato all'argomento

ciao  :Smile: 

----------

## darkmanPPT

ok, ho visto il tuo post.

interessante... ma alla fine?

alla fine c'e' una mini sequenza di comandi, ma a me nn vanno....

dicamo... quando faccio emerge -e system ad un cero punto mi da errore su alcune librerie....

dice che non trova i386-pc-...

cioe'

per dire che il thread non e' esaudiente!

----------

## Cazzantonio

ugualmente potevi proseguire su quello come caldamente raccomandano le linee guida

P.S. le linee guida raccomandano anche di cercare prima di postare   :Wink: 

thread mergiato

----------

## darkmanPPT

ma insomma, qualcuno mi sa dire perchè nn riesco a fare emerge -e system?

ho fatto alla lettera le cose descritte:

 *Quote:*   

> Quindi ricapitolando i passi da seguire sono questi (seguendo la guida all'aggiornamento di gcc):
> 
> 1) emerge gcc
> 
> 2) emerge --oneshot libsdtv++-v3
> ...

 

ad un certo punto arrivo a groff (e poi capita anche a file)

in cui iniziano a richiedere i386-pc-linux-.... etc etc

ovviamente, avendi ira selezionato i686-pc-....

mi torna un errore di gcc-conf che dice che i386-pc-.... non lo trova

 *Quote:*   

> gcc-config error: Could not run/locate "i386-pc-linux-gnu-gcc"

 

qualcuno mi sa dire come cavolo fare?

su un altro pc ho fatto la stessa cosa e non ho avuto alcun problema. l'unica diff tra i due è che sull'altro non è stato ancora installato x11, xorg-11, kde, etc etc... tutta quella roba grafica là...

come fare??

----------

## bandreabis

Ho scaricato lo stage3-i686 e un /urs ho i486-pc-linux-gnu e solo dopo un emerge --sync ho trovato i686-pc-linux-gnu.

E' normale?

----------

## mack1

@bandreabis

Ho installato gentoo su un portatile circa un mese fa con il tuo stesso stage e i486 era presente .... non so se sia normale ma ad installazione finita(previo backup anti murphy  :Cool:  ) visto che i686 era presente ho brutalmente piallato i486 .... senza conseguenze visibili x gentoo  :Cool:  !

Ciao

----------

