Forum Debian Users Gang

Jacekalex napisał(-a):

która wersja gcc 4.4.* działa prawidłowo?

U mnie działała każda z obecnie dostępnych :D

Przy jakich progamach i jakie komunikaty są w ostatnich kilkunastu linijkach?
Może to nie jest wina gcc.

Nie chcę tworzyć nowego wątku, więc dopiszę się tutaj.

Zrobiłem

emerge --update --deep world
emerge -p --depclean
revdep-rebuild
dipatch-conf

Najważniejszą zmianą, jaką przyniosła aktualizacja, była zmiana kompilatora z 4.3.4 na gcc-4.4.3-r2 ale tylko na systemie 64-bitowym, bo na 32 wciąż jest 4.3.4 (przynajmniej w tym momencie było) - co mnie zmartwiło, bo do skrośnej kompilacji potrzebne są te same wersje kompilatora czyli 4.3.4 (nie mógłbym zatem zaprząc blaszaka do udziału w kompilacji na laptoku). Ale olałem sprawę licząc na to, że jak pojawi się nowy kompilator na x86 to sobie naprawię distcc. Wróciłem więc do dalszego udoskonalania systemu.

A ponieważ był chłodny wieczór, to zapuściłem jeszcze dla pewności

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

Potem znów

emerge -p --depclean
revdep-rebuild
dipatch-conf

Efekt był dość ciekawy, o czym dowiadywałem się stopniowo (w międzyczasie wywaliłem stary kompilator). Pierwszy problem zgłosił mplayer (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

Gugiel wspominał coś o spieprzonym kompilatorze. 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

Kompilator do x86 potrzebny jest do distcc ale dlaczego był domyślny i czy to oznacza, że przekompilowałem sobie system nie tym kompilatorem?

Nie mam ochoty na naprawy, przywrócę system z backupu ale jestem ciekaw, gdzie spieprzyłem sprawę?

Ale tam się zrobił totalny bajzel z kompilatorami, bo miałem 2:
1) właściwy, dla 86_64, do wczoraj był w wersji 4.3.4
2) toolchain do kompilacji skrośnej czyli i686 ale on był wywoływany tylko przez distcc czyli tak naprawdę z laptopa (laptop uruchamiał gdy kompilował, bo laptop jest x86), normalnie jak coś instalowałem na blaszaku, to korzystał ze swojego;

Potem oba kompilatory przeskoczyły do wersji 4.4.3 ale to jest bardzo dziwne. O ile dla 86_64 na wczoraj był kompilator w wersji 4.4.3, o tyle nie było go dla wersji x86. Zatem nie jest dziwne, że gcc dla 86_64 przeskoczył z 4.3.4 na 4.4.3. Dziwne jest to, że przeskoczył dla wersji x86 skoro używam stable. Ponadto nie rozumiem, jak on się zupgrejdował z automatu, skoro dotychczasowe "małe" zmiany, np. 4.3.3 na 4.3.4 nadpisywały toolchaina i musiałem go od nowa tworzyć. A tu proszę - nie dość, że się sam zupgrejdował (i to do wersji z unstable),  to zrobił sobie toolchaina, wybrał się na default i przekompilował system z 64 na 32 bity. :)

A system był totalnie rozpieprzony, bo jak tylko zamknąłem firefoksa, to już się nie dało go uruchomić ponownie, ze względu na brak bibliotek.

O ile wiem, że może zbyt szybko wywaliłem gcc 4.3.4 (chociaż akurat to robiłem z otwartym handbookiem) o tyle kompletnie nie rozumiem, jakim cudem toolchain się sam zupgrejdował, nie nadpisał i stał się domyslnym kompilatorem.....

No wiadomo, winny ten, kto wciska enter

Ale skąd u licha wziął się ten kompilator

i686-pc-linux-gnu-4.4.3

Edyta:
Coś nie bardzo kopia systemu chce wrócić :) Chyba zacznę od początku....

A może by tak funtoo?

Ostatnio edytowany przez ippo76 (2010-05-29 13:22:25)

ArnVaker napisał(-a):

....
Przecież możesz zrobić tak:

Kod:

emerge -avuDN world

i dostaniesz wszystko przejrzyście, do tego z pytaniem czy się zgadzasz :)

Czy nie wychodzi na to samo?

ippo76 napisał(-a):

Kod:

emerge -p --depclean

ArnVaker napisał(-a):

Udawany depclean? hmm...

Hehe, nie wspomniałem o tych 4 piwach....

ippo76 napisał(-a):

Kod:

revdep-rebuild
dipatch-conf

ArnVaker napisał(-a):

Ja daję odwrotnie ;]....

ArnVaker napisał(-a):

.... gcc jest przecież slotowane, nikt Ci nie każe zmieniać wersji w danym momencie :)

Kod:

grep gcc /var/lib/portage/world
sys-devel/gcc:4.3
sys-devel/gcc:4.4

Nie kumam slotów ;) Po prostu po pierwszym --update zainstalowal się nowy kompilator

ArnVaker napisał(-a):

...
To chłodny tydzień chyba musiał być :D

A zdziwiłbyś się, na rano blaszak był gotowy (i to dosłownie :) ) a laptok męczył się jeszcze do popołudnia, z 16-godzin mu zeszło lekko (ale za to przeżył tę operację).

ArnVaker napisał(-a):

Przekompilowanie @system cztery razy, całej reszty dwa razy przez zmianę kompilatora z 4.3.4 na 4.4.3? "Trochę" absurd :)

A bo przeczytałem o tym na forum, ze tak trzeba, żeby wyszło jak w stage1 :) A potem już byłem pijany i poooszłooo...

ArnVaker napisał(-a):

...

"Tym tropem" (gcc-config -l) to się idzie przy zmianie kompilatora, nie wiem jakim Ty wcześniej szedłeś xD

Nie, no ja tak handbooka zarozumiałem - że przejście z 1.2.2 na 1.2.3 to pryszcz ale z 1.2.3 na 2.1.1 to już hoho!

No i wpadłem na to, żeby wszystko tym nowym kompilatorem przekompilować wzdłuż i wszerz. A potem doczytałem, żeby usunąć stary :)

ArnVaker napisał(-a):

....
Tiaa, wszystko "sam"... sorry, ale coś chrzanisz :)

No niestety nie udokumentowałem wszystkich kroków ale popieprzyły się 2 sprawy:
1) zmiana kompilatora dla blaszaka z 4.3.4 na 4.4.3
2) zmienił się kompilator dla laptoka czyli toolchain dla distcc.
O ile w p. 1 sam narozrabiałem, o tyle w p. 2 - nie. Przecież wrzucałem miesiąc temu wątek, że distcc przestał mi działać. Tu dygresja - jeśli robię --update na laptoku albo instaluję coś dużego, to uruchamiam distcc i na obu kompach zmieniam /etc/make.conf zwiększając liczbę procesorów. Wtedy portage na laptopie "angażuje" blaszaka i kompilacja dla laptoka odbywa się na obu maszynach. Ponieważ laptok jest x86 a blaszak 86_64 trzeba zbudować toolchain dla distcc czyli na blaszaku robię drugi kompilator dla x86 (konktetnie podaję wg /etc/make.conf z laptoka czyli i686-pc-linux-gnu i taki toolchain mi się tworzy dla innej architektury. Handbook dokładnie opisuje, jakie czynności na której maszynie trzeba wykonać i to akurat u mnie działało. Z małym wyjątkiem - kiedy zmieniała się wersja gcc, distcc się wyłożył (kompilacja szła tylko na laptoku, a w treści na ekranie widać było komunikaty o błędzie distcc, blaszak w ogóle nie brał udziału w kompilacji - to widać w htopie) i dopiero odbudowa toolchaina rozwiązała problem. Nie zapisywałem zmian wersji gcc ale poprzednia zmiana była "mała" czyli np. z 4.3.3 na 4.3.4 - a mimo to toolchain został pewnie nadpisany i distcc na laptoku informował o błędach, a na blaszaku nic się nie kompilowało dla laptoka.

Jeśli kompilowałem coś na blaszaku, to blaszak robił to sam i swoim kompilatorem. A w tym przypadku - sądząc po tym

* gcc-config: Active gcc profile is invalid!
[1] i686-pc-linux-gnu-4.4.3 *

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

przekompilowałem sobie system toolchainem zamiast natywnym kompilatorem.

Tylko dlaczego do tej pory takie jaja się nie działy? Jakim cudem toolchain stał się domyślnym kompilatorem? Zapewniam, że po komendzie

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

wydanej na obu komputerach i to w konsoli nie miałem już nic do roboty i poszedłem spać. Resztę zniszczenia dokonałem na drugi dzień, kiedy już wszystko było przekompilowane...

No i najlepsze - przecież wczoraj i dziś nie było gcc w wersji 4.4.3 dla stable.... Sam ją sobie stworzyłem?

*  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

ippo76 napisał(-a):

A może by tak funtoo?

Nie, chcę gentoo na obu maszynach - ze względu na distcc. Kopii nie udało mi się przywrócić, więc bedę stawiał stable na nowo. W związku z tym prośba o zweryfikowanie:


Po postawieniu systemu ze stage3 robię:
1) emerge --sync
2) kompiluję system i świat ze swoimi flagami i CFLAGS i CXXFLAGS poprzez

emerge -e system && emerge -e world

i uzyskuję efekt jakbym zainstalował system ze stage1
3) instaluję resztę systemu na swoich flagach (j.w.) i w związku z tym nie ma sensu robić emerge -e system && emerge -e world
4) jakie są przesłanki do wykonania emerge -e system && emerge -e world? Zmiana kompilatora? Jeśli tak, to jaka?

Ostatnio edytowany przez ippo76 (2010-05-29 16:38:19)

Właśnie tym się posiłkowałem (tyle że w polskiej wersji), po

 emerge -e system

zrobiłem

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

Tyle, że u mnie jako domyślny był toolchain dla i686. Po wyczyszczeniu za pomocą emerge -aC programy nie chciały się już uruchamiać, zgłaszając błędy w bibliotekach. Dopóki firefoxbył otwarty (uruchomiłem go przed czyszczeniem) to działał, po zamknięciu już nie wstał (brakujące biblioteki).

Jasne jest, że spieprzyłem system, tylko chciałbym wiedzieć na przyszłość, czego nie robić.

Na razie obstawiam distcc. Domyślnie jest wyłączony na obu maszynkach. Ale dla tak dużej kompilacji chciałem ulżyć lapkowi. Uruchomiłem distcc na obu maszynach i powinienem puścić kompilację na lapku. Ale zmieniłem zamiar i najpierw postanowiłem zrobić upgrade na blaszaku. Po tej operacji zmieniła się wersja kompilatora na blaszaku, więc użycie kompilacji skrośnej nie było już możliwe. A dalej już wiadomo jak poszło.

ArnVaker napisał(-a):

...
Jak nie? No jest przecież...

Nawet dziś nie ma. Jest 4.3.4

ArnVaker napisał(-a):

Ja nie używam distcc i kompilacji skrośnej ale jeżeli dobrze łapię, to Ty nie instalujesz gcc z innej architektury, tylko tym swoim natywnym gcc kompilujesz dla niej cały toolchain opierając się na wersjach (numerkach) zainstalowanych z architektury natywnej. Czyli imo jest ok :)

1. Na obu komputerach musi być kompilator w tej samej wersji http://www.gentoo.org/doc/pl/distcc.xml
2. Dla kompilacji skrośnej na maszynie wspomagającej trzeba utworzyć toolchain dla maszynyw spomaganej, czyli blaszak swoim natywnym kompilatorem tworzy toolchain i686-pc-linux-gnu-gcc.

Ale sądząc po efekcie, to mój system na blaszaku przekompilowałem toolchainem skoro programy zaczęły płakać na brakujące biblioteki. Ponadto -moim zdaniem - świadczy o tym to:

 * gcc-config: Active gcc profile is invalid!
 [1] i686-pc-linux-gnu-4.4.3 *

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

.

Zgodnie z tym zapisem (na samym dole) samo uruchomienie distcc na blaszaku mogło spowodować jego "przestawienie" się w tryb toolchaina. Mój błąd polegał na tym, że powinienem rozpocząć kompilację na lapku, a zamiast tego najpierw zaktualizowałem system na blaszaku z uruchomionym distcc. Tylko tak to mogę logicznie wytłumaczyć, ale nie przekonuje mnie to do końca...

ArnVaker napisał(-a):

...
Sam przecież napisałeś w pierwszym poście..
...
Kompilatorem 4.4.3 utworzyłeś potem toolchain do pomocy lapkowi — w wersjach takich jak zainstalowane w systemie, wszystko się zgadza :)

Tak, to jest jasne. Na x86_64 gcc zmieniło wersję i przebudował się toolchain. Na x86 wciąż jest stara wersja (4.3.4).
Ale miesiąc temu narzekałem, że distcc mi przestał działać. Musiałem go tworzyć na nowo i uznałem, że zapewne aktualizacja gcc nadpisała pliki. A tym razem poszło z automatu?

ArnVaker napisał(-a):

I niby czyja to wina? Przecież to użytkownik ustawia wersję kompilatora używaną przez system :)

Kod:

amidala / # gcc-config -l
 [1] x86_64-pc-linux-gnu-4.3.4
 [2] x86_64-pc-linux-gnu-4.4.4 *

Kod:

amidala / # gcc-config 2
 * Switching native-compiler to x86_64-pc-linux-gnu-4.4.4 ...

tak jest nawet w handbooku na który się powoływałeś napisane:

(Należy zmienić "i686-pc-linux-gnu-4.1.1" na odpowiednią wersję GCC oraz ustawienie zmiennej CHOST)
# gcc-config i686-pc-linux-gnu-4.1.1

Ale ja nie wykonałem żadnego z tych kroków! Nie zmieniałem kompilatora, nie edytowałem żadnych plików!
1) Uruchomiłem distcc na obu maszynach
2) Zamiast zrobić emerge -e world na lapku, zrobiłem emerge --update --deep world na blaszaku i dalej na blaszaku:
3) Zrobiłem emerge --depclean revdep-rebuild dispatch-conf
4) Zrobiłem poczwórną kompilację, potem znów emerge --depclean revdep-rebuild dispatch-conf
5) W związku z tym, że wiedziałem o zmianie kompilatora, wykonałem emerge -aC "<sys-devel/gcc-4.4.3-r2"
czyli pozbyłem się starego kompilatora 4.3.4.
6) Nie odbudowywałem toolchaina
7) Nie wybierałem go jako domyślny kompilator...

Ostatnio edytowany przez ippo76 (2010-05-30 17:38:32)

No dobra — nie potrafię wykombinować co dokładnie się sypnęło i dlaczego xD (za pierwszym razem - ditcc itd.)

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

A jak aktualizujesz kompilator to rób tak jak jest w handbooku!!!

po skompilowaniu nowego sprawdzasz dostępne:

amidala / # gcc-config -l
 [1] x86_64-pc-linux-gnu-4.3.4
 [2] x86_64-pc-linux-gnu-4.4.4 *

wybierasz nowy:

amidala / # gcc-config 2
 * Switching native-compiler to x86_64-pc-linux-gnu-4.4.4 ...

env-update && source /etc/profile

puszczasz fix_libtool_files.sh na stary:

fix_libtool_files.sh 4.3.4

gotujesz libtool:

emerge -avq1 libtool

i dopiero robisz co tam miałeś robić dalej :)

Jak nie ma jak jest...

Listing 4.1: Aktualizacja GCC

# emerge -uav gcc
(Należy zastąpić "i686-pc-linux-gnu-3.4.5" odpowiednią wersją GCC i nazwą CHOST)
# gcc-config i686-pc-linux-gnu-3.4.5
# source /etc/profile

(Ponowna kompilacja libtool)
# emerge --oneshot -av libtool

czytaj całość a nie wybiórczo :)

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


EDIT: kompilator nie jest spieprzony — używam go od miesięcy xD

Skompilowałeś nowy kompilator, ale się na niego nie przełączyłeś. Przekompilowałeś system starym po czym go usunąłeś ;]

Ostatnio edytowany przez ArnVaker (2010-05-30 22:10:41)

No i co ja biedny szary użyszkodnik mam Ci odpowiedzieć? U mnie wszystko działa, nic się nie sypie, nic się nie robi "samo"... wsio gra :)