Instalowanie GCC-3.3.1 - przebieg 2

Estimated build time:           11.0 SBU
Estimated required disk space: 274 MB

Ponowna instalacja GCC

Teraz są już zainstalowane narzędzia do testowania  GCC i Binutils (Tcl, Expect oraz DejaGnu). Możemy iść dalej, reinstalując GCC i Binutils, linkując je przy użyciu nowej Glibc i odpowiednio testując. Trzeba jedno zaznaczyć, mianowicie że te zestawy testowe są bardzo uzależnione od prawidłowego działania pseudoterminali (PTY'sów) które udostępnia nasza dystrybucja macierzysta. Obecnie są one najczęściej implementowane przez system plików  devpts. Możesz szybko sprawdzić, czy twój system hosta jest dobrze ustawiony pod tym względem, wykonując prosty test:

expect -c "spawn ls"

Jeśli otrzymasz wiadomość "W systemie nie ma więcej PTY'sów. Poproś swojego administratora żeby utworzył więcej.":

The system has no more ptys.  Ask your system administrator to create more.

to twoja dystrybucja macierzysta nie jest prawidłowo ustawiona pod względem działąnia pseudotermianli PTY. W takim prypadku nie ma sensu wykonywać zestawów testowych dla GCC i Binutils, dopóki nie będziesz umiała poradzić sobie z tym. Możesz sprawdzić na LFS Wiki pod adresem http://wiki.linuxfromscratch.org/, tam znajdziesz więcej informacji, jak sprawić, by pseudoterminale działały.

Rozpakuj wszystkie trzy tarballe GCC (-core, -g++, oraz -testsuite) w jednym i tym samym katalogu roboczym. One wszystkie rozwiną się do jednego podkatalogu gcc-3.3.1/.

Najpierw popraw jeden problem i zrób zasadnicze dopasowanie:

patch -Np1 -i ../gcc-3.3.1-no_fixincludes-2.patch
patch -Np1 -i ../gcc-3.3.1-specs-2.patch

Pierwsza łatka wyłącza skrypt GCC "fixincludes". Wcześniej wspomnieliśmy o tym, ale tu będzie nieco głębsze wyjaśnienie procesów fixincludes. W normalnych warunkach skrypt GCC fixincludes przgląda twój system w poszukiwaniu plików nagłówkowych do poprawienia. Mógby znaleźć pliki nagłówkowe Glibc twojego systemu macierzystego, poprawić je i przenieść do własnego katalogu GCC include. Zatem później, w Rozdziale 6, gdy zainstalujemy nowszą Glibc, ten prywatny katalog include zostanie przeszukany wcześniej, niż systemowy katalog include. Wynikiem będzie znalezienie poprawionych nagłówków z systemu macierzystego, które na ogół nie pasowałyby do wersji Glibc używanej w rzeczywistości w systemie LFS.

Ostatnia łatka zamienia domyślną lokalizację dynamicznego linkera GCC (zwykle ld-linux.so.2). Usuwa również /usr/include ze ścieżki przeszukiwania include GCC. Łatanie zamiast poprawiania pliku specyfikacji po zainstalowaniu, zapewnia że nasz nowy dynamiczny linker będzie użyty podczas właściwego budowania GCC. To znaczy, że wszystkie końcowe ( i tymczasowe) binaria utworzone podczas budowy będą linkowane względem tej nowej Glibc.

Ważne: Te łatki są niezbędne do szczęśliwego zbudowania całości. Nie zapomnij ich użyć.

Utwórz znów oddzielny katalog budowy:

mkdir ../gcc-build
cd ../gcc-build

Przed rozpoczęciem budowy GCC, pamiętaj aby wyłączyć wszystkie zmienne środowiskowe, które mogłyby nadpisać domyślne flagi optymalizacji.

Teraz przygotuj GCC do kompilacji:

../gcc-3.3.1/configure --prefix=/tools \
--with-local-prefix=/tools \
--enable-clocale=gnu --enable-shared \
--enable-threads=posix --enable-__cxa_atexit \
--enable-languages=c,c++

Znaczenie nowych opcji configure:

Skompiluj pakiet:

make

There is no need to use the bootstrap target now, as the compiler we're using to compile this GCC was built from the exact same version of the GCC sources we used earlier. Nie ma potrzeby używania docelowego bootstrap ponieważ nasz kompilator użyty do kompilacji tej kolekcji GCC został zbudowany z tych samych źródeł, których użyliśmy wcześniej.

Uwaga: Watro zaznaczyc, że wykonania zestawów testowych tutaj uważa się za nie tak ważne, jak w Rozdziale 6.

Sprawdź wyniki:

make -k check

Flaga -k ma spowodować, że test będzie wykonywany w całości i nie zatrzyma się po pierwszym błędzie. Zestaw testowy jesxt zupełnie wyczerpujący i masz prawie pewne uzyskanie kilku błędów. Żeby przejrzeć podsumowanie wyników tego testu wykonaj:

../gcc-3.3.1/contrib/test_summary | more

Możesz porównać twoje wyniki z tymi, jakie przysłano na listę wysyłkową gcc-testresults dla podobnej konfiguracji jak twoja. Jak chcesz zobaczyć, jak powinny wyglądać dla aktualnej GCC-3.3.1 na "trójce docelowej" i686-pc-linux-gnu, zobacz: http://gcc.gnu.org/ml/gcc-testresults/2003-08/msg01612.html.

Zauważ, że wyniki zawierają:

* 1 XPASS (unexpected pass) for g++
* 1 FAIL (unexpected failure) for g++
* 2 FAIL for gcc
* 26 XPASS's for libstdc++

Ten "nieprzewidziany przebieg" (unexpected pass) dla g++ to ze względu na zastosowanie --enable-__cxa_atexit. Wygląda na to, że nie wszystkie platformy obsługiwane przez GCC mają w swoich bibliotekach C obsługę "__cxa_atexit", więc ten test nie zawsze musi przejść.

Nieprzewidziane 26 przebiegów dla libstdc++ pojawiło się z powodu zastosowania opcji --enable-clocale=gnu, która jest prawidłowym wyborem dla systemów opartych na Glibc  w wersji 2.2.5 lub nowszej. The underlying locale support in the GNU C library is superior to that of the otherwise selected "generic" model (which may be applicable if for instance you were using Newlibc, Sun-libc or whatever libc). Obsługa podległych lokalizacji w bibliotece GNU C  jest nadrzędna względem lokalizacji inaczej określanych w modelu "ogólnym" ("generic"), które mogą być stosowane jeśli, na przykład używałaś Newlibc, Sun-libc albo jakiejś innej libc. Widocznie zestaw testowy libstdc++ spodziewa się modelu "ogólnego", a więc te testy nie zawsze muszą się powieść.

Nieraz pojawiają się niespodziewane błędy. Developerzy GCC zazwyczaj się ich wystrzegają, ale jeszce nie poradzili sobie z wyszukaniem i poprawieniem wszystkich. Krótko mówiąc, o ile twoje wyniki nie różnieą się w większym zakresie od tych pokazywanych na podanej wyżej stronie, to można bezpiecnie kontynuować.

A na koniec zainstaluj pakiet:

make install

Uwaga: W tym momencie usilnie zalecamy powtórzyć sprawdzenie czystości, które wykonywaliśmy wcześniej w tym rozdziale. Powróć do Sekcji p.t. "Domknięcie" Glibc i powtórz tamto sprawdzenie. Jeśli wyniki są nieprawidłowe, to najprawdopodobniej zapomniałaś zastosować łatkę specyfikacji GCC Specs patch.