Zmiana wartości zmiennej CHOSTZmiana wartości zmiennej CHOST może być problemem, który poważnie może uszkodzić system. Zatem dlaczego jest do tego w ogóle przewodnik? Istnieje sporo przypadków, kiedy zmiana wartości zmiennej CHOST jest nieunikniona, np. jeśli chce się zaktualizować glibc 2.4, które wspiera tylko nptl, a zmienna CHOST to i386, co uniemożliwia wykorzystanie nptl. W takim wypadku nie ma zbyt dużej liczby rozwiązań problemu. Zmiana wartości zmiennej CHOST jest jedną z nich. Nawet jeśli wykona się poniższe instrukcje, mogą powstać problemy, dlatego trzeba być podczas całego procesu bardzo uważnym. W tym przykładzie zmienna CHOST będzie zmieniania z i386 na i686. Aby dokonać zmiany z innych wartości zmiennej CHOST, należy zmienić odpowiednio komendy. 2. Zmiana wartości zmiennej CHOST Aby zmienić wartość zmiennej CHOST, otwieramy plik /etc/make.conf i zmieniamy wartość CHOST na taką, jakiej potrzebujemy. Potem należy przebudować następujące pakiety:
Sprawdzenie wprowadzonych zmian Teraz sprawdzimy czy ustawienia gcc-config i binutils-config są w porządku i czy nie ma żadnych pozostałości w /etc/env.d/. Wynik poleceń gcc-config i binutils-config powinien wyglądać mniej więcej tak jak poniżej (mogą się nieznacznie różnić z zależności od wersji gcc i wartości CHOST). My podajemy przykłady dla wersji 4.1.1 i 2.16.1.
Następnie wyszukujemy odwołania do starej wartości zmiennej CHOST w katalogu /etc/env.d/:
Przed skasowaniem tego pliku należy sprawdzić pliki ze zaktualizowaną wartością zmiennej CHOST:
Ten plik wygląda dobrze. Jest tylko jeden problem. Powinien być tylko jeden plik dla gcc w katalogu /etc/env.d/ (05gcc w tym przykładzie), więc kasujemy ten drugi z niepoprawnym odwołaniem:
To same kroki należy wykonać dla binutils. Jeśli jest jakiś dodatkowy niepasujący do wersji zmiennej CHOST plik, należy go usunąć. Następnie sprawdzamy katalog /etc/env.d/binutils/
Ten katalog wygląda dobrze, te dwa pliki powinny w nim zostać. Teraz czas na przejście do katalogu gcc.
Pliki config i i686-pc-linux-gnu-4.1.1 wyglądają w porządku, ale plik config-i386-pc-linux-gnu jest kolejną pozostałością do usunięcia.
Następnie wykonujemy poniższe komendy, aby zaktualizować środowisko:
Następnie sprawdzamy czy wszystko jest w porządku:
Jeśli ciągle istnieją niepoprawne odwołania, najprawdopodobniej pominięto jakiś plik. Trzeba znaleźć go ręcznie przed przejściem dalej. Następnie koniecznie należy przekompilować pakiet libtool i wykonać polecenie /usr/share/gcc-data/$CHOST/<gcc-version>/fix_libtool_files.sh. Należy upewnić się, że używa się odpowiedniej wersji gcc. Zmienną $CHOST zastępujemy nową wartością CHOST, a <gcc-version> nową wersją gcc. W przykładzie tym przyjęto i686 jako wartość CHOST.
Teraz jest dobra okazja by przebudować cały system:
Przebudowa systemu jest wskazana, ale nie konieczna, poza tym nie ma 100% pewności, że to ten przypadek. Jeśli nie przebudowano całego systemu na pewno pewne pakiety wymagają rekompilacji. Zaczynamy od:
Pakiety związane z perlem instalują się do katalogu, który ma zmienną CHOST w nazwie. W związku z tym należy je teraz wszystkie przebudować. Jeśli w systemie nie ma jeszcze programu qfile, trzeba będzie najpierw zainstalować pakiet app-portage/portage-utils.
Jeśli jakiś pakiet nie wymieniony w tym dokumencie wymaga przebudowy po zmianie CHOST, należy o tym poinformować autora tego dokumentu. Po aktualizacji gcc z wersji 3.3 do 4.1 z równoczesną zmianą zmiennej CHOST (nie jest to wskazane), kilku użytkowników zgłosiło, że pakiety takie jak groff i courier wymagają rekompilacji:
Dzieje się tak, ponieważ po aktualizacji zmienna CHOST nie pasuje do zmiennej CTARGET i kompilator wybiera kompilację skrośną (ang. cross-compiling). W konsekwencji zmienna LDPATH nie zostaje załadowana do ld.so.conf, powodując ten błąd. Aby dowiedzieć się, co trzeba zrobić po przejściu na inną wersję gcc, należy przeczytać tekst o aktualizacji gcc. W rzadkich przypadkach może to również spowodować popsucie starych wersji pythona. Może to zostać naprawione poprzez dodanie /usr/lib/gcc-lib/i386-pc-linux-gnu/3.3.6 (należy odpowiednio zmienić wartość chost i wersję gcc na używane poprzednio) w /etc/ld.so.conf, wykonać polecenie ldconfig i dopiero wtedy emerge libstdc++-v3. Jednak jak widać powinno się unikać tego problemu - stąd wniosek: nie powinno się zmieniać wartości zmiennej CHOST z jednoczesną aktualizacją gcc. Wszelkie komentarze na temat tego tekstu (zarówno pozytywne jak i konstruktywną krytykę) należy przesyłać na adres Wernfried Haas lub publikować w tym wątku na forum. Sporą część tego tekstu napisał vapier, dziękujemy! Materiał udostępniany na podstawie licencji Creative Commons - Attribution / Share Alike. |
|