Nie jesteś zalogowany.
Jeśli nie posiadasz konta, zarejestruj je już teraz! Pozwoli Ci ono w pełni korzystać z naszego serwisu. Spamerom dziękujemy!
Prosimy o pomoc dla małej Julki — przekaż 1% podatku na Fundacji Dzieciom zdazyć z Pomocą.
Więcej informacji na dug.net.pl/pomagamy/.
Pytanie może dziwne, ale rzeczywiste.
stawiam dość "świeży" system Gentoo (x86 ~x86) i mam mały klopot.
obecne gcc 4.4.3 - działa niby fajnie, ale - przy niektórych paczkach zatrzymuje się w trakcie, i cieszy odpoczynkiem, przez resztę tysiąclecia).
Przykładowo dla biblioteki libgcrypt wygląda to tak:
fPIC -DPIC -o mpi-cmp.o >/dev/null 2>&1 i686-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I.. -I../src -I../src -march=prescott -O2 -pipe -fomit-frame-pointer -fvisibility=hidden -Wall -c mpi-gcd.c -fPIC -DPIC -o .libs/mpi-gcd.o i686-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I.. -I../src -I../src -march=prescott -O2 -pipe -fomit-frame-pointer -fvisibility=hidden -Wall -c mpi-gcd.c -fPIC -DPIC -o mpi-gcd.o >/dev/null 2>&1
- i na tym koniec szychty (dalej drzemka).
a szkoda- mam około 130 paczek przebudowanych tą wersją gcc (4.4.3).
teraz instaluję gcc 4.4.2, ale jesli w tym tez coś będzie nie tak - to będzie raczej ......
w totolotka jestem raczej kiepski.
Obecna wersja:
# gcc -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-4.4.3/work/gcc-4.4.3/configure --prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/4.4.3 --includedir=/usr/lib/gcc/i686-pc-linux-gnu/4.4.3/include --datadir=/usr/share/gcc-data/i686-pc-linux-gnu/4.4.3 --mandir=/usr/share/gcc-data/i686-pc-linux-gnu/4.4.3/man --infodir=/usr/share/gcc-data/i686-pc-linux-gnu/4.4.3/info --with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/4.4.3/include/g++-v4 --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --disable-altivec --disable-fixed-point --without-ppl --without-cloog --enable-nls --without-included-gettext --with-system-zlib --disable-checking --disable-werror --enable-secureplt --disable-multilib --enable-libmudflap --disable-libssp --enable-libgomp --enable-cld --with-python-dir=/share/gcc-data/i686-pc-linux-gnu/4.4.3/python --disable-libgcj --with-arch=i686 --enable-languages=c,c++,fortran --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.4.3 p1.0' Thread model: posix gcc version 4.4.3 (Gentoo 4.4.3 p1.0)
emerge --info: http://wklej.org/id/312543/
Pozdrawiam
Ostatnio edytowany przez Jacekalex (2010-06-28 23:10:56)
Offline
[quote=Jacekalex]która wersja gcc 4.4.* działa prawidłowo?[/quote]
U mnie działała każda z obecnie dostępnych :D
Offline
[i] sys-devel/gcc (4.4.3(4.4)@10.02.2010): The GNU Compiler Collection. Includes C/C++, java compilers, pie+ssp extensions, Haj Ten Brugge runtime bounds checking [i] sys-devel/gcc (4.3.4(4.3)@10/29/09 4.4.3(4.4)@02/18/10): The GNU Compiler Collection. Includes C/C++, java compilers, pie+ssp extensions, Haj Ten Brugge runtime bounds checking [i] sys-devel/gcc (4.3.4(4.3)@02/19/10 4.4.3(4.4)@02/21/10): The GNU Compiler Collection. Includes C/C++, java compilers, pie+ssp extensions, Haj Ten Brugge runtime bounds checking
Offline
Przy jakich progamach i jakie komunikaty są w ostatnich kilkunastu linijkach?
Może to nie jest wina gcc.
Offline
A nie jest tak, że po prostu grzeje Ci się klocek? ;) U mnie jak się grzał to też się zatrzymywało, potem po chwili ruszało z miejsca, a częściej zawisło całkiem i koniec. Niektóre rzeczy udawało się skompilować inne nie. To też moim zdaniem raczej nie będzie wina kompilatora.
Ja tam mam 4.4.3, bo mi kazał aktualizować ten wyżej w tym czarnym cylindrze ;)
Ostatnio edytowany przez marg1 (2010-04-09 10:57:23)
Offline
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ę [tt]distcc[/tt]. 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 [tt]mmx[/tt]). 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 [tt]distcc[/tt] ale dlaczego był [tt]domyślny[/tt] 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ę?
Offline
ippo zanim wywalisz kompilator zmień ten aktywny w systemie ;] Powinieneś w ten sposób uniknąć przynajmniej części z opisanych problemów - ale to tylko moje zdanie a ja się nie znam
Offline
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 [tt]distcc[/tt] 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.....
Offline
ippo samo to się wiesz co robi :P Coś przekombinowałeś po prostu i tyle
Offline
No wiadomo, winny ten, kto wciska [tt]enter[/tt]
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)
Offline
Kurde... to po co klepiesz tak: [tt]emerge --update --deep world[/tt]?
Przecież możesz zrobić tak:
emerge -avuDN world
i dostaniesz wszystko przejrzyście, do tego z pytaniem czy się zgadzasz :)
[quote=ippo76]
emerge -p --depclean
[/quote]
Udawany depclean? hmm...
[quote=ippo76]
revdep-rebuild dipatch-conf
[/quote]
Ja daję odwrotnie ;] taki standard pod dwa aliasy w sumie, na upartego jeden:
layman -S && eix-sync && emerge -avquDN world --keep-going dispatch-conf && emerge -a --depclean && revdep-rebuild && lafilefixer --justfixit
[quote=ippo76]Najważniejszą zmianą, jaką przyniosła aktualizacja, była zmiana kompilatora z 4.3.4 na gcc-4.4.3-r2[/quote]
gcc jest przecież slotowane, nikt Ci nie każe zmieniać wersji w danym momencie :)
grep gcc /var/lib/portage/world sys-devel/gcc:4.3 sys-devel/gcc:4.4
[quote=ippo76]A ponieważ był chłodny wieczór, to zapuściłem jeszcze dla pewności[/quote]
To chłodny tydzień chyba musiał być :D
Przekompilowanie @system cztery razy, całej reszty dwa razy przez zmianę kompilatora z 4.3.4 na 4.4.3? "Trochę" absurd :)
http://www.funtoo.org/en/funtoo/events/changes/sch-2010.2.html http://www.gentoo.org/doc/pl/gcc-upgrading.xml
[quote=ippo76]Poszedłem tym tropem:[/quote]
"Tym tropem" ([tt]gcc-config -l[/tt]) to się idzie przy zmianie kompilatora, nie wiem jakim Ty wcześniej szedłeś xD
[quote=ippo76]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. :)[/quote]
Tiaa, wszystko "sam"... sorry, ale coś chrzanisz :)
==================
[quote=ippo76]A może by tak funtoo?[/quote]
[quote=ippo76][quote=ArnVaker]Natomiast jak już wcześniej pisałem - gdybym stawiał na gałąź stabilną - zainstalowałbym Funtoo.[/quote]
A ja zrobię Ci na złość (i marg1emu, rzecz jasna) i czepię się gentoo (jak pijany płotu).[/quote]
Offline
[quote=ArnVaker]....
Przecież możesz zrobić tak:
emerge -avuDN world
i dostaniesz wszystko przejrzyście, do tego z pytaniem czy się zgadzasz :)[/quote]
Czy nie wychodzi na to samo?
[quote=ippo76]
emerge -p --depclean
[/quote]
[quote=ArnVaker]Udawany depclean? hmm...[/quote]
Hehe, nie wspomniałem o tych 4 piwach....
[quote=ippo76]
revdep-rebuild dipatch-conf
[/quote]
[quote=ArnVaker]Ja daję odwrotnie ;]....[/quote]
[quote=ArnVaker].... gcc jest przecież slotowane, nikt Ci nie każe zmieniać wersji w danym momencie :)
grep gcc /var/lib/portage/world sys-devel/gcc:4.3 sys-devel/gcc:4.4
[/quote]
Nie kumam slotów ;) Po prostu po pierwszym [tt]--update[/tt] zainstalowal się nowy kompilator
[quote=ArnVaker]...
To chłodny tydzień chyba musiał być :D[/quote]
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ę).
[quote=ArnVaker]Przekompilowanie @system cztery razy, całej reszty dwa razy przez zmianę kompilatora z 4.3.4 na 4.4.3? "Trochę" absurd :)[/quote]
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...
[quote=ArnVaker]...
"Tym tropem" ([tt]gcc-config -l[/tt]) to się idzie przy zmianie kompilatora, nie wiem jakim Ty wcześniej szedłeś xD[/quote]
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 :)
[quote=ArnVaker]....
Tiaa, wszystko "sam"... sorry, ale coś chrzanisz :)[/quote]
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 [tt]toolchain[/tt] dla [tt]distcc[/tt].
O ile w p. 1 sam narozrabiałem, o tyle w p. 2 - nie. Przecież wrzucałem miesiąc temu wątek, że [tt]distcc[/tt] przestał mi działać. Tu dygresja - jeśli robię [tt]--update[/tt] na laptoku albo instaluję coś dużego, to uruchamiam distcc i na obu kompach zmieniam [tt]/etc/make.conf[/tt] zwiększając liczbę procesorów. Wtedy [tt]portage[/tt] na laptopie "angażuje" blaszaka i kompilacja dla laptoka odbywa się na obu maszynach. Ponieważ laptok jest x86 a blaszak 86_64 trzeba zbudować [tt]toolchain[/tt] dla [tt]distcc[/tt] czyli na blaszaku robię drugi kompilator dla x86 (konktetnie podaję wg [tt]/etc/make.conf[/tt] z laptoka czyli [tt]i686-pc-linux-gnu[/tt] i taki [tt]toolchain[/tt] mi się tworzy dla innej architektury. [tt]Handbook[/tt] 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, [tt]distcc[/tt] się wyłożył (kompilacja szła tylko na laptoku, a w treści na ekranie widać było komunikaty o błędzie [tt]distcc[/tt], blaszak w ogóle nie brał udziału w kompilacji - to widać w htopie) i dopiero odbudowa [tt]toolchaina[/tt] rozwiązała problem. Nie zapisywałem zmian wersji [tt]gcc[/tt] ale poprzednia zmiana była "mała" czyli np. z 4.3.3 na 4.3.4 - a mimo to [tt]toolchain[/tt] został pewnie nadpisany i [tt]distcc[/tt] 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[/quote]
przekompilowałem sobie system [tt]toolchainem[/tt] zamiast natywnym kompilatorem.
Tylko dlaczego do tej pory takie jaja się nie działy? Jakim cudem [tt]toolchain[/tt] stał się domyślnym kompilatorem? Zapewniam, że po komendzieKod:
emerge -e system && emerge -e system && emerge -e world && emerge -e worldwydanej 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...
[b]No i najlepsze - przecież wczoraj i dziś nie było gcc w wersji 4.4.3 dla stable....[/b] Sam ją sobie stworzyłem?Kod:
* 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[quote=ippo76]A może by tak funtoo?[/quote]
Nie, chcę gentoo na obu maszynach - ze względu na [tt]distcc[/tt]. 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 [tt]stage3[/tt] robię:
1) [tt]emerge --sync[/tt]
2) kompiluję system i świat ze swoimi flagami i [tt]CFLAGS[/tt] i [tt]CXXFLAGS[/tt] poprzezKod:
emerge -e system && emerge -e worldi uzyskuję efekt jakbym zainstalował system ze [tt]stage1[/tt]
3) instaluję resztę systemu na swoich flagach (j.w.) i w związku z tym nie ma sensu robić [tt]emerge -e system && emerge -e world[/tt]
4) jakie są przesłanki do wykonania [tt]emerge -e system && emerge -e world[/tt]? Zmiana kompilatora? Jeśli tak, to jaka?Ostatnio edytowany przez ippo76 (2010-05-29 16:38:19)
ippo76@jid.dug.net.pl
Moja składka do ZUS = 2/3, moja składka do OFE = 1/3;
Stan mojego konta w ZUS = 2XYZ, stan konta w OFE = 3XYZ.
Offline
Luknij tu http://www.gentoo.org/doc/en/gcc-upgrading.xml chodzi o ten błąd podane rozwiązanie
* gcc-config: Active gcc profile is invalid!
[1] i686-pc-linux-gnu-4.4.3 *
[2] x86_64-pc-linux-gnu-4.4.3
Offline
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ł [tt]toolchain[/tt] dla i686. Po wyczyszczeniu za pomocą [tt]emerge -aC[/tt] programy nie chciały się już uruchamiać, zgłaszając błędy w bibliotekach. Dopóki [tt]firefox[/tt]był 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 [tt]distcc[/tt]. Domyślnie jest wyłączony na obu maszynkach. Ale dla tak dużej kompilacji chciałem ulżyć lapkowi. Uruchomiłem [tt]distcc[/tt] na obu maszynach i powinienem puścić kompilację na lapku. Ale zmieniłem zamiar i najpierw postanowiłem zrobić [tt]upgrade[/tt] 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.
Offline
[quote=ippo76]Czy nie wychodzi na to samo?[/quote]
nie
[quote=ippo76]Nie kumam slotów ;)[/quote]
Bo nie używasz eix...
[i] sys-devel/gcc
Available versions:
[b][color=#dc0000](2.95)[/color][/b] *2.95.3-r9 ~*2.95.3-r10!s
[b][color=#dc0000](3.1)[/color][/b] *3.1.1-r2
[b][color=#dc0000](3.2)[/color][/b] **3.2.2!s *3.2.3-r4
[b][color=#dc0000](3.3)[/color][/b] (~)3.3.6-r1!s
[b][color=#dc0000](3.4)[/color][/b] 3.4.6-r2!s
[b][color=#dc0000](4.0)[/color][/b] ~*4.0.4!s
[b][color=#dc0000](4.1)[/color][/b] 4.1.2!s
[b][color=#dc0000](4.2)[/color][/b] (~)4.2.4-r1!s
[b][color=#dc0000](4.3)[/color][/b] 4.3.2-r3!s (~)4.3.2-r4!s (~)4.3.3-r2!s 4.3.4!s
[b][color=#dc0000](4.4)[/color][/b] (~)4.4.1!s (~)4.4.2!s 4.4.3-r2!s 4.4.3-r6!s[1] (~)4.4.4-r2!s[1]
[b][color=#dc0000](4.5)[/color][/b] [M]**4.5.0!s [M]**4.5.0-r3!s[1][/quote]
Jasno widać, że na slocie 4.3 są wersje 4.3.x, na slocie 4.4 wersje 4.4.x — nie bardzo jest tu czego nie rozumieć :)
[tt]emerge -avq gcc[/tt] — najnowsze dostępne gcc (dla danej wersji z systemu, w oparciu o package.mask, package.keywords itp.)
[tt]emerge -avq gcc:4.4[/tt] — najnowsze gcc na slocie 4.4, czyli w powyższym przykładzie 4.4.4-r2
[tt]emerge -avq gcc:4.3[/tt] — najnowsze gcc na slocie 4.3, tutaj 4.3.4Kod:
grep gcc /var/lib/portage/world sys-devel/gcc sys-devel/gcc:4.3 sys-devel/gcc:4.4Czyli mam zawsze najnowsze gcc, ponadto najnowsze na slocie 4.4 i najnowsze na slocie 4.3 — depclean ich nie ruszy nawet jak przejdę na 4.5.x
[quote=ippo76]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...[/quote]
Nie no proszę Cię... kompilować @system cztery razy ot tak... po co? Tutaj raz to aż nadto :)
BTW, @system zawiera się w @world — po co kompilować najpierw system, a potem world, skoro [tt]emerge -e world[/tt] i tak przekompiluje @system?
[quote=ippo76]Nie, no ja tak handbooka zarozumiałem - że przejście z 1.2.2 na 1.2.3 to pryszcz ale z [b]1.2.3[/b] na [b]2.1.1[/b] to już hoho![/quote]
Z tego co piszesz wynika, że masz na myśli przejście przykładowo z 4.3.4 na 5.1.1 :)
Przy tym konkretnym przejściu nic nie trzeba "nadprogramowo" przekompilować xDIt is not necessary to rebuild any other parts of your system, and there are no known issues transitioning from the old libstdc++ in gcc-4.3.3-r2 to the new libstdc++ in gcc-4.4.3, or transitioning from the older glibc to the newer glibc.[/quote]
[quote=ippo76]No i najlepsze - przecież wczoraj i dziś nie było gcc w wersji 4.4.3 dla stable.... Sam ją sobie stworzyłem?[/quote]
Jak nie? No jest przecież... 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 :)
[img]http://svn.debianart.org/themes/generic/spinner/spinner48px-moreblue.png[/img]Offline
[quote=ArnVaker]...
Jak nie? No jest przecież...[/quote]
Nawet dziś nie ma. Jest 4.3.4
[quote=ArnVaker]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 :)[/quote]
1. Na obu komputerach musi być kompilator w tej samej wersji [url]http://www.gentoo.org/doc/pl/distcc.xml[/url]
2. Dla kompilacji skrośnej na maszynie wspomagającej trzeba utworzyć [tt]toolchain[/tt] dla maszynyw spomaganej, czyli blaszak swoim natywnym kompilatorem tworzy [tt]toolchain i686-pc-linux-gnu-gcc[/tt].
Ale sądząc po efekcie, to mój system na blaszaku przekompilowałem [tt]toolchainem[/tt] 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
.
[url=http://www.gentoo.org/doc/pl/cross-compiling-distcc.xml]Zgodnie z tym zapisem[/url] (na samym dole) samo uruchomienie [tt]distcc[/tt] na blaszaku mogło spowodować jego "przestawienie" się w tryb [tt]toolchaina[/tt]. Mój błąd polegał na tym, że powinienem rozpocząć kompilację na lapku, a zamiast tego najpierw zaktualizowałem system na blaszaku z uruchomionym [tt]distcc[/tt]. Tylko tak to mogę logicznie wytłumaczyć, ale nie przekonuje mnie to do końca...
Offline
[quote=ippo76]Nawet dziś nie ma. Jest 4.3.4[/quote]
Sam przecież napisałeś w pierwszym poście..
[quote=ippo76]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[/quote]
Kompilatorem 4.4.3 utworzyłeś potem toolchain do pomocy lapkowi — w wersjach takich jak zainstalowane w systemie, wszystko się zgadza :)
[quote=ippo76]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.[/quote]
I niby czyja to wina? Przecież to użytkownik ustawia wersję kompilatora używaną przez system :)
amidala / # gcc-config -l [1] x86_64-pc-linux-gnu-4.3.4 [2] x86_64-pc-linux-gnu-4.4.4 *
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[/quote]
[img]http://svn.debianart.org/themes/generic/spinner/spinner48px-moreblue.png[/img]
Offline
[quote=ArnVaker]...
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 :)[/quote]
Tak, to jest jasne. Na x86_64 gcc zmieniło wersję i przebudował się [tt]toolchain[/tt]. Na x86 wciąż jest stara wersja (4.3.4).
Ale miesiąc temu narzekałem, że [tt]distcc[/tt] 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?
[quote=ArnVaker]I niby czyja to wina? Przecież to użytkownik ustawia wersję kompilatora używaną przez system :)
amidala / # gcc-config -l [1] x86_64-pc-linux-gnu-4.3.4 [2] x86_64-pc-linux-gnu-4.4.4 *
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[/quote]
[/quote]
Ale ja nie wykonałem żadnego z tych kroków! Nie zmieniałem kompilatora, nie edytowałem żadnych plików!
1) Uruchomiłem [tt]distcc[/tt] na obu maszynach
2) Zamiast zrobić [tt]emerge -e world[/tt] na lapku, zrobiłem [tt]emerge --update --deep world[/tt] na blaszaku i dalej na blaszaku:
3) Zrobiłem [tt] emerge --depclean revdep-rebuild dispatch-conf[/tt]
4) Zrobiłem poczwórną kompilację, potem znów [tt] emerge --depclean revdep-rebuild dispatch-conf[/tt]
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 [tt]toolchaina[/tt]
7) Nie wybierałem go jako domyślny kompilator...Ostatnio edytowany przez ippo76 (2010-05-30 17:38:32)
ippo76@jid.dug.net.pl
Moja składka do ZUS = 2/3, moja składka do OFE = 1/3;
Stan mojego konta w ZUS = 2XYZ, stan konta w OFE = 3XYZ.
Offline
K%^&a mać!
zainstalowałem w chroocie system bazowy, zrobiłem [tt]emerge -s world[/tt]. Pół dnia się mieliło,wreszcie koniec. Wypadałoby posprzątać:
emerge --depclean ... Calculating dependencies... done! sys-devel/gcc selected: 4.3.4 protected: none omitted: 4.4.3-r2 >>> 'Selected' packages are slated for removal. >>> 'Protected' and 'omitted' packages will not be removed. >>> Waiting 5 seconds before starting... >>> (Control-C to abort)... >>> Unmerging in: 5 4 3 2 1 >>> Unmerging sys-devel/gcc-4.3.4... openpty failed: 'out of pty devices' * gcc-config: Could not locate 'x86_64-pc-linux-gnu-4.3.4' in '/etc/env.d/gcc/' ! * Running 'fix_libtool_files.sh 4.3.4' * Scanning libtool files for hardcoded gcc library paths... cat: ld.so.conf.d/*.conf: Nie ma takiego pliku ani katalogu gcc-config: error: could not run/locate 'gcc' :0: assertion failed: (gcc -dumpversion) | getline NEWVER) Packages installed: 143 Packages in world: 4 Packages in system: 50 Required packages: 143 Number removed: 1
No to sprzątam dalej:
revdep-rebuild bash: revdep-rebuild: nie znaleziono polecenia
No tak, musiałem zapomnieć...
Klepię [tt]emerge gentoolkit[/tt] i dostaję:
gcc-config: error: could not run/locate 'x86_64-pc-linux-gnu-gcc' make[1]: *** [_build/realpath.o] Error 1 make: *** [all] Error 2 * ERROR: app-misc/realpath-1.15 failed: * emake failed * * Call stack: * ebuild.sh, line 54: Called src_compile * environment, line 2328: Called die * The specific snippet of code: * emake VERSION="${PV}" SUBDIRS="src man $(use nls && echo po)" || die "emake failed" * * If you need support, post the output of 'emerge --info =app-misc/realpath-1.15', * the complete build log and the output of 'emerge -pqv =app-misc/realpath-1.15'. * The complete build log is located at '/var/tmp/portage/app-misc/realpath-1.15/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/app-misc/realpath-1.15/temp/environment'. * S: '/var/tmp/portage/app-misc/realpath-1.15/work/realpath-1.15'
O co tu, k#$%a chodzi?
Jeszcze jedna ciekawostka:
emerge --info !!! No gcc found. You probably need to 'source /etc/profile' !!! to update the environment of this terminal and possibly !!! other terminals also.
Edyta:
te pedały coś spieprzyły:
[url]http://bugs.gentoo.org/show_bug.cgi?id=321941[/url]
Ostatnio edytowany przez ippo76 (2010-05-30 22:01:34)
Offline
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 [tt]fix_libtool_files.sh[/tt] na stary:
fix_libtool_files.sh 4.3.4
gotujesz [tt]libtool[/tt]:
emerge -avq1 libtool
i dopiero robisz co tam miałeś robić dalej :)
Offline
Słowa o tym nie ma: [url]http://www.gentoo.org/doc/pl/gcc-upgrading.xml#first-install-emerge-e[/url]
Wygląda na to, że wrzucili jakiś spieprzony kompilator do "stable".. No i jest stabilnie, jak w archu....
Teraz to ja mam już znów spieprzony system.
Ostatnio edytowany przez ippo76 (2010-05-30 22:08:00)
Offline
Jak nie ma jak jest...
[b]Listing 4.1: Aktualizacja GCC[/b][/quote]
# 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[/quote]
czytaj całość a nie wybiórczo :)
========================
[b]EDIT:[/b] 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)
[img]http://svn.debianart.org/themes/generic/spinner/spinner48px-moreblue.png[/img]Offline
Ktoś przecież zgłosił buga, że ten kompilator jest niestabilny. A poza tym, jakoś tego weekendu kompilator zamieniał się sam, jak mu było wygodnie, a innym razem jechał wg [tt] handbooka[/tt]... :)
No super po prostu. Zmienić jedną wersję na drugą trzeba ręcznie ale przekompilowanie systemu [tt]toolchainem[/tt] dzieje się automagicznie, jakoś tak na śfintego Jana.... Normalnie [tt]Noc cudów[/tt] jak w salonie fiata :)
Kupujta ludzie gentoo ;)
Ostatnio edytowany przez ippo76 (2010-05-30 22:18:44)
Offline
No i co ja biedny szary użyszkodnik mam Ci odpowiedzieć? U mnie wszystko działa, nic się nie sypie, nic się nie robi [i]"samo"[/i]... wsio gra :)
Offline
To wpisz to magiczne zaklęcie do poczwórnej kompilacji ;) Debian jest najlepszy :D
Ostatnio edytowany przez ippo76 (2010-05-30 22:21:41)
Offline
Time (s) | Query |
---|---|
0.00013 | SET CHARSET latin2 |
0.00010 | SET NAMES latin2 |
0.00163 | SELECT u.*, g.*, o.logged FROM punbb_users AS u INNER JOIN punbb_groups AS g ON u.group_id=g.g_id LEFT JOIN punbb_online AS o ON o.ident='3.145.176.228' WHERE u.id=1 |
0.00065 | REPLACE INTO punbb_online (user_id, ident, logged) VALUES(1, '3.145.176.228', 1732483139) |
0.00041 | SELECT * FROM punbb_online WHERE logged<1732482839 |
0.00041 | SELECT topic_id FROM punbb_posts WHERE id=148908 |
0.00008 | SELECT id FROM punbb_posts WHERE topic_id=16561 ORDER BY posted |
0.00044 | SELECT t.subject, t.closed, t.num_replies, t.sticky, f.id AS forum_id, f.forum_name, f.moderators, fp.post_replies, 0 FROM punbb_topics AS t INNER JOIN punbb_forums AS f ON f.id=t.forum_id LEFT JOIN punbb_forum_perms AS fp ON (fp.forum_id=f.id AND fp.group_id=3) WHERE (fp.read_forum IS NULL OR fp.read_forum=1) AND t.id=16561 AND t.moved_to IS NULL |
0.00007 | SELECT search_for, replace_with FROM punbb_censoring |
0.00207 | SELECT u.email, u.title, u.url, u.location, u.use_avatar, u.signature, u.email_setting, u.num_posts, u.registered, u.admin_note, p.id, p.poster AS username, p.poster_id, p.poster_ip, p.poster_email, p.message, p.hide_smilies, p.posted, p.edited, p.edited_by, g.g_id, g.g_user_title, o.user_id AS is_online FROM punbb_posts AS p INNER JOIN punbb_users AS u ON u.id=p.poster_id INNER JOIN punbb_groups AS g ON g.g_id=u.group_id LEFT JOIN punbb_online AS o ON (o.user_id=u.id AND o.user_id!=1 AND o.idle=0) WHERE p.topic_id=16561 ORDER BY p.id LIMIT 0,25 |
0.00063 | UPDATE punbb_topics SET num_views=num_views+1 WHERE id=16561 |
Total query time: 0.00662 s |