Ponowna regulacja zestawu narzędziowego

Teraz, gdy zainstalowały się nowe biblioteki C, przyszedł czas na ponowną regulację naszego zastawu narzędziowego. Wyregulujemy go tak, aby linkował (łączył) nowo kompilowane programy stosując nowe biblioteki C. Zasadniczo to jest odwrotność tego, co robiliśmy na etapie "domykania" przy początku poprzedniego rozdziału.

Najpierw wyregulujemy linker. W tym celu zachowaliśmy katalogi źródłowy i budowy, z drugiego przebiegu dla Binutils. Zainstaluj poprawiony linker wykonując w katalogu binutils-build co nastepuje:

make -C ld INSTALL=/tools/bin/install install

Uwaga: Jeśli jakoś ci umknęło wcześniejsze ostrzeżenie, aby zachować katalogi źródeł i budowy Binutils z drugiego przebiegu w Rozdziale 5 albo przypadkiem je skasowałaś lub po prostu nie masz teraz dostępu do nich, nie martw się, nie wszystko stracone. Po prostu zignoruj powyższe polecenie. Efektem będzie, że następny pakiet, Binutils, będzie linkowany przy użyciu bibliotek z katalogu /tools a nie /usr. To nie najlepsze, ale z naszych testów wynika, że powstałe binarne programy Binutils powinny być identyczne.

Od teraz każdy kompilowany program będzie łączony tylko z bibliotekami z katalogów /usr/lib i /lib. Dodatkowa zmienna INSTALL=/tools/bin/install jest potrzebna, bo  Makefile utworzony podczas drugiego przebiegu nadal zawiera odniesienie do  /usr/bin/install, którego oczywiście jeszcze nie mamy zainstalowanego. Niektóre dystrybucje macierzyste (host) mają link symboliczny ginstall który ma pierwszeństwo w  Makefile a to może tu sprawiać problemy. Powyższa komenda załatwia nam również i to.

Teraz możesz usunąć katalogi źródłowy i budowy Binutils.

Następne do zrobienia są poprawki w pliku specyfikacji GCC, żeby wskazywał na nowy dynamiczny linker. Tak, jak wcześniej, użyjemy sed-a aby to osiągnąć:

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

I znów, zaleca się wycinanie i wklejanie napisów. I tak, jak poprzednio, dobrze byłoby sprawdzić plik specyfikacji, żeby upewnić się, że zrobione zmiany są takie, jak trzeba.

Ważne: Jeśli pracujesz na platformie sprzętowej, której dynamiczny linker ma inną nazwę, niż ld-linux.so.2, to musisz zastąpić ld-linux.so.2 właściwą nazwą linkera dynamicznego dla twojej platformy, w powyższej komendzie. W razie potrzeby wróć do Sekcji Techniczne uwagi na temat zestawu narzędziowego w Rozdziale 5.

 

Ostrzeżenie

W tym miejscu koniecznie trzeba się zatrzymać i upewnić się, że podstawowe funkcje poprawionego zestawu narzędziowego (okmpiolwanie i łączenie - linkowanie) działają jak powinny. W tym celu przeprowadzimy prosty zdroworozsądkowy sprawdzian:

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

Jeśli wszystko działa prawidłowo, to nie powinno być żadnych błędów, a komunikat wyjściowy ostatniego polecenia powinien wyglądać tak:

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

Jeśli nie dostałaś takiego komunikatu wyjściowego, albo nie dostałaś go wcale, to masz coś naprawdę źle. Będziesz musiała prześledzić i powtórzyć wszystkie kroki, aby dowiedzieć się,  w czym jest problem i go naprawić. Nie ma mowy o kontynuowaniu, dopóki tego nie zrobisz. Najbardziej prawdopodobne, że coś się zepsuło przy poprawianiu pliku specyfikacji powyżej. W szczególności zauważ, że teraz jako prefix naszego dynamicznego linkera pojawia się /lib. Oczywiście, jeśli pracujesz na platformie, gdzie dynamiczny linker ma inną nazwę, niż  ld-linux.so.2, to powyższy komunikat wyjściowy będzie nieco inny.

Kiedy już jesteś zadowolona, że wszystko jest dobrze, posprzątaj pliki testowe:

rm dummy.c a.out