# Rozwaliłem system kompilatorem

## ippo

Witam wszystkich jako nowy użytkownik gentoo. Przepraszam z góry, jeśli umieściłem wątek w złym miejscu. 

Postawiłem sobie ze 2 miesiące temu gentoo stable na dwóch komputerkach: lapek (x86 - pentium m) oraz blaszak (86_64 athlon). Ponieważ lapek jest wyraźnie słabszy, więc aby ulżyć mu w kompilacji używałem distcc - po standardowej instalacji z handbooka działało wszystko bezproblemowo. Ponieważ lapek jest na dzisiejsze standardy już dość słaby, zainstalowałem na nim wszystko co najlżejsze (fluxbox, abiword, moc, mplayer, itp.). Do instalacji takich pierdółek raczej distcc nie był potrzebny ale dla rekompilacji systemu owszem (bawię się flagami optymalizując system  :Smile:  ). 

Pierwszy schodek miał miejsce na początku maja. Gdy chcę zrobić rekompilację systemu na lapku z nową flagą, uruchamiam z palca distcc na obu maszynach, potem emerge robi wszystko sam - efekt widzę na blaszaku za pomocą htopa - wzrasta obciążenie obu rdzeni, pamięci, najbardziej zasobożernym procesem jest distcc). Jednak tym razem wyłowiłem na ekranie taki komunikat: 

```

distcc[24403] ERROR: compile cairo-analysis-surface.c on 192.168.0.4 failed with exit code 110

distcc[24403] (dcc_build_somewhere) Warning: remote compilation of 'cairo-analysis-surface.c' failed, retrying locally
```

Jak się później okazało, któraś z aktualizacji przyniosła zapewne zmianę wersji kompilatora, bo pomogło zbudowanie na nowo  toolchaina . Nie wiem tego na pewno ale taki jest logiczny wniosek. Problem został rozwiązany ale należało pamiętać o odbudowie toolchaina po każdej zmianie wersji kompilatora. Ma to znaczenie w dalszej części tej opowieści.

Teraz najbardziej wstydliwy wątek: w szale optymalizacji postanowiłem zastosować się do tej  porady. Uruchomiłem distcc na obu maszynach i - zamiast zacząć od lapka, postanowiłem najpierw zaktualizować system na blaszaku. Wykonałem kolejno 

```
emerge --update --deep world

emerge --depclean

revdep-rebuild

dipatch-conf

```

W trakcie zauważyłem, że zmieniła się wersja kompilatora - dotychczas na obu maszynach był gcc-4.3.4 (taki jest warunek konieczny dla kompilacji skrośnej - ta sama wersja kompilatora), a tymczasem dla 86_64 zmienił się nagcc-4.4.3-r2. Zapamiętałem ten fakt, bo to oznaczało, że nie skorzystam z distcc kompilując na laku, bo:

1) musiałbym odbudować toolchain - zgodnie z wcześniejszym doświadczeniem, ale to i tak nic by nie dało, bo: 

2) kompilator dla architektury x86 pozostał w wersji gcc-4.3.4: 

```

*  sys-devel/gcc

      Latest version available: 4.3.4

      Latest version installed: 4.3.4

      Size of files: 59,405 kB

      Homepage:      http://gcc.gnu.org/

      Description:   The GNU Compiler Collection. Includes C/C++, java compilers, pie+ssp extensions, Haj Ten Brugge runtime bounds checking

      License:       GPL-3 LGPL-3 || ( GPL-3 libgcc libstdc++ ) FDL-1.2
```

czyli dotarło do mnie, że niestety lapek będzie musiał wykonać kompilację własnymi siłami.

Wydałem więc w konsoli (X-y były wyłączone) na obu maszynach komendę: 

```
emerge -e system && emerge -e system && emerge -e world && emerge -e world
```

 i poszedłem spać.

Na drugi dzień gotowy był tylko blaszak. Wpisałem więc: 

```

emerge --depclean

revdep-rebuild

dipatch-conf
```

a potem dodatkowo 

```
emerge -aC "<sys-devel/gcc-4.4.3-r2"
```

 i od tego momentu zaczęły się dziać dziwne rzeczy. Nie mogłem uruchomić mplayera ze względu na brak jakiejś biblioteki. Nie chciało mi się szukać problemu, więc go wywaliłem i próbowałem zainstalować na nowo. Wysypał mi błędy dotyczące braku obsługi jakichś funkcji przez jądro (jednym z wielu było tajemnicze mmx). Chciałem sprawdzić, co to za cholerstwo ale efekt nie był zachęcający: 

```
zcat /proc/config.gz | grep -E 'mmx' 

gzip: /proc/config.gz: No such file or directory
```

Dalej było już tylko gorzej (postanowiłem pogrzebać w jajku):

```
make menuconfig

  HOSTCC  scripts/basic/fixdep

gcc-config: error: could not run/locate 'gcc'

make[1]: *** [scripts/basic/fixdep] Błąd 1

make: *** [scripts_basic] Błąd 2
```

Wg googla wyglądało to na zepsuty kompilator. Poszedłem tym tropem:

```
 * gcc-config: Active gcc profile is invalid!

 [1] i686-pc-linux-gnu-4.4.3 *

 [2] x86_64-pc-linux-gnu-4.4.3
```

Potem zdechł firefoks - gdy go zamknąłem to nie mogłem go już ponownie otworzyć - brakujące biblioteki.

Jeśli dobrze to odczytuję, to przekompilowałem sobie system 64-bitowy toolchainem dla laptoka? Ale jak to możliwe, skoro:

1) po zmianie kompilatora toolchain trzeba było budować na nowo;

2) jakim cudem toolchain stał się domyślnym kompilatorem w systemie (czyżby włączony distcc?

3) dlaczego do tej pory system wiedział, kiedy używać swojego kompilatora (CFLAGS=86_64-pc-linux-gnu-4.x.y) gdy coś instalowałem na blaszaku, a kiedy użyć toolchaina współkompilując dla lapka programy z CFLAGS=i686-pc-linux-gnu-4.x.y;

4) czyżbym zbudował sobie sam kompilator w wersji 4.4.3?

Wybaczcie rozwlekłość tego wywodu ale chciałem w miarę dokładnie opisać sytuację, a i tak zabrakło wielu informacji, ponieważ nie zapisywałem wyników wszystkich kroków, mając w perspektywie przywrócenie systemu z backupu.

Ostatecznie musiałem postawić system od nowa ale proszę o wskazanie, gdzie popełniłem błędy. Złośliwości można sobie darować, zostałem już ukarany  :Smile: 

Ostania uwaga: kompilacja na lapku zakończyła się sukcesem.

----------

## ippo

Niestety, zostałem ukarany za to, że nie przeczytałem uważnie podręcznika:

 *Quote:*   

> 
> 
> 5.  Częste problemy
> 
> Przed aktualizacją (nieważne którą metodą) należy wyłączyć distcc (jeśli się go używa). Mieszanie wersji kompilatorów może spowodować problemy z kompilacją. Nie jest to wymagane w przypadku ccache, ponieważ obiekty z ccache zostaną i tak unieważnione. 
> ...

 

----------

