"Domknięcie" Glibc

Teraz, mając zainstalowane tymczasowe biblioteki C, chcemy aby wszystkie nowe narzędzia, jakie skompilujemy w dalszej części tego rozdziału, były linkowane (łączone) z zastosowaniem tych bibliotek. Aby tego dokonać musimy poprawić plik specyfikacji kompilatora i linkera. To accomplish this, we need to adjust the linker and the compiler's specs file.

Najpierw zainstaluj poprawiony linker wykonując co następuje, w katalogu binutils-build:

make -C ld install

Ten linker został poprawiony przed chwilą, pod koniec pierwszego przebiegu Binutils. Od tej chwili wszystko będzie się linkować wyłącznie przy użyciu bibliotek z /tools/lib.

Uwaga: Jeśli umknęło twojej uwadze ostrzeżenie, aby zachować źródło Binutils oraz katalogi budowy z pierwszego przebiegu, albo nieszczęśliwym zbiegiem okoliczności skasowałaś je, albo po prostu nie masz już dostępu do nich, nie martw się, jeszcze nie wszystko stracone. Po prostu zignoruj powyższe polecenie. Powstanie niewielka szansa, że późniejsze programy będą linkowane w oparciu o biblioteki z hosta. To nie jest idealna rozwiązanie, jednakże nie jest to największy z problemów. Sytuacja wróci do normy gdy zainstalujemy Binutils w drugim przebiegu, trochę później.

Teraz, gdy jest już zainstalowany poprawiony linker, musisz usunąć katalogi: budowy oraz źródłowy Binutils.

Kolejną rzeczą do zrobienia jest wniesienie poprawek w pliku specyfikacji GCC, aby wskazywał na nowy linker dynamiczny. Dokona tego prosty sed:

SPECFILE=/tools/lib/gcc-lib/*/*/specs &&
sed -e 's@ /lib/ld-linux.so.2@ /tools/lib/ld-linux.so.2@g' \
$SPECFILE > tempspecfile &&
mv -f tempspecfile $SPECFILE &&
unset SPECFILE

Zalecamy, abyś raczej wycięła i wkleiła to co wyżej, niż wpisywała wszystko z klawiatury. A mozesz też edytować ten plik specyfikacji "z palca", jeśli masz ochotę: po prostu zastąp każde wystąpienie "/lib/ld-linux.so.2" przez "/tools/lib/ld-linux.so.2".

Ważne: Jeśli pracujesz na platformie sprzętowej, której dynamiczny linker ma nazwę inną niż ld-linux.so.2, to musisz zastąpić ld-linux.so.2 nazwą dynamicznego linkera dla tej platformy, w powyższych poleceniach. W razie potrzeby korzystaj z Sekcji pod_nazwą Toolchain technical notes.

Na koniec, istnieje możliwość, że niektóre pliki dołączane, z macierzystego systemu (host system) dostały się do prywatnego katalogu dołączeń (include) GCC. Może tak się zdarzyć, ponieważ ze względu na proces GCC "fixincludes", który działa jako część budowania (build) GCC. Trochę więcej w tej mierze wyjaśnimy dalej w tym rozdziale. Jak na razie, wykonaj następujące polecenia, aby wyeliminować tą możliwość:

rm -f /tools/lib/gcc-lib/*/*/include/{pthread.h,bits/sigthread.h}

 

Ostrzeżenie

W tym miejscu musisz koniecznie zatrzymać się i upewnić, że podstawowe czynności (kompilowanie i linkowanie - łączenie) nowego zestawu narzędziowego działają tak, jak tego oczekujemy. W tym celu przeprowadzimy prosty zdroworozsądkowy sprawdzian:

echo 'main(){}' > dummy.c
gcc dummy.c
readelf -l a.out | grep ': /tools'

Jeśli wszystko działa prawidłowo, to nie powinno być żadnych błędów, a na wyjściu ostatniej komendy będzie:

[Requesting program interpreter: /tools/lib/ld-linux.so.2]

Jeśli nie dostałaś wyjściowego komunikatu jak powyżej, albo nie dostałaś żadnego, to coś jest całkiem źle. Będziesz musiała prześledzić, odtwarzając swoje kroki, aby dowiedzieć się, co było powodem tego problemu i naprawić to. Nie ma mowy o żadnej kontynuacji, dopóki tego nie zrobisz. Najbardziej prawdopodobne, że coś poszło nie tak przy poprawianiu pliku specyfikacji powyżej. Szczególnie sprawdź, czy jako prefiks naszego dynamicznego linkera występuje /tools/lib. Oczywiście, jeśli pracujesz na platformie, gdzie dynamicznym linkerem jest coś innego niż ld-linux.so.2, to komunikat wyjściowy będzie nieco inny.

Gdy już wiesz, że wszystko jest dobrze, wyczyść pliki testowe:

rm dummy.c a.out

 

Tak kończymy instalację samodzielnego zestawu narzędziowego, i teraz można go używać podczas budowy pozostałych narzędzi tymczasowych.