Wednesday, 4. March 2009, 18:46:14
Już jakiś czas temu doszedłem do wniosku, że GCC 4.3.3 powinno być dostatecznie bezpieczne do codziennego użytku i kusiła mnie migracja na tę wersję. Większość
bugów na
bugzilli Gentoo jest zamknięta, a niedobitki to pakiety, których w życiu nie używałem. Postanowiłem więc zakasać rękawy i przystąpić do aktualizacji i przebudowy systemu
Spostrzeżenia i uwagi:
* Odmaskowałem glibc 2.8*, bo nie chciałem się pakować od razu w 2.9
* Najpierw odmaskowałem nowe wersje
boost,
boost-build i
aspella. Wersje ze stable rzekomo nie lubią się z GCC 4.3
* Dodatkowo zaktualizowałem
VirtualBoksa do wersji
2.1.4 z overlaya
jokey. Wersje 2.1.0+ dodają wsparcie dla GCC 4.3
* Po przełączeniu kompilatora zmieniłem -march na -march=native, żeby przerzucić dobór optymalizacji na kompilator
* emerge -e @system przebiegło bezboleśnie
* Pierwszy problematycznym pakietem przy emerge -e @world okazała się
enca. Wystarczyło odmaskować
enca i jej zależność -
recode* Dużo później wyłożył się
dev86, zależność m.in.
VirtualBoksa i kernelowego
uvesafb. Wystarczyło odmaskować.
* Dzięki -march=native wyłożyła się oczywiście (z racji boostrapowania) rekompilacja starego GCC, ale to już rozwiązałem za pomocą portage-bashrc-ng i package.*flags.
* Wyłożyła się też
Stepmania z roslina. Dodałem do repo stosowną łatkę, głównie dodającą brakujące nagłówki.
* Na koniec wyłożył się stary
Amarok. I to byłby najdziwniejszy problem. Po zmniejszeniu MAKEOPTS na -j1 przeszło bez problemu (choć pod GCC 4.1.2 i -j5 było wszystko cacy). Mało tego, później na -j5 i GCC 4.3 poszło jak gdyby nigdy nic. Nie będę nawet starał się tego zrozumieć. Tak będzie lepiej
* Na koniec na wszelki wypadek przekompilowałem kernel i zrobiłem module-rebuild.
* Stary kompilator zostawiłem na potrzeby distcc (o pewnej sztuczce z tym związanej napiszę w późniejszym poście)
Uwagi końcowe:
Wszystko przebiegło pomyślnie i, o ile pamięć służy, było dużo mniej wpadek niż jakiś czas temu przy przejściu na 4.1. Tym razem skończyło się na odmaskowaniu 5 pakietów (+ VirtualBoksa z overlaya) i jednej własnej łatce. Wynik uważam za korzystny. Podczas rekompilacji system był w pełni sprawny. Normalnie z niego korzystałem. Jedyną usterką, jaką zaobserwowałem była ciut ogłupiała konsola Pythona zanim ten został przekompilowany
Nowe GCC wypluwa dużo więcej ostrzeżeń, głównie za sprawą domyślnie włączonych
-D_FORTIFY_SOURCE=2 i -Wformat-security. Na razie nie zauważyłem cudownych wzrostów wydajności ani zmniejszenia rozmiaru binarek. Z drugiej strony, nie robiłem żadnych pomiarów przed i po. Niemniej jednak efekt placebo jest bardzo satysfakcjonujący
Zresztą GCC 4.3 i tak trafi do stable w perspektywie najbliższych tygodni. Przyśpieszyłem tylko nieuniknione
O ile jesteście gotowi odmaskować parę pakietów i przekompilować system, mogę wam z powodzeniem polecić tę wersję GCC.
UPDATE:
Nowy VirtualBox właśnie wylądował w portage. Nie jest już potrzebny overlay.
Z mniej optymistycznych wieści:
*
cvs wykłada się z "
*** %n in writable segment detected ***" przy cvs diff. Na szczęście wystarczyło odmaskować najnowszą wersję.
*
zsnes wykłada się z powodu -D_FORTIFY_SOURCE. Jest już na to
łatka. Zaraz będzie w roslinie
UPDATE 2:
Po odpaleniu debuggera w emulatorze snes9x odkryłem problem na linii FORTIFY_SOURCE i glibc 2.8. Ma on wpływ na programy używające sprintf (i inne jego warianty) do doklejania tekstu do końca bufora w taki sposób:
sprintf(buf, "%sfail", buf);
Teoria jest taka, że taki kod jest nieprawidłowy i nie powinno się tak pisać. W praktyce mamy wiele programów, które tego nadużywają. Kilka wystąpień znalazłem nawet w źródłach kernela. Błąd występuje tylko przy włączonym FORTIFY_SOURCE i optymalizacji -O2 (i pewnie wyższych. Na szczęście jest na to łatwe obejście. Wystarczy nałożyć
tę łatkę na glibc. Przywraca on stare zachowanie. Po nałożeniu łatki nie trzeba przekompilowywać systemu, ale jeśli bardzo chcecie, to proszę bardzo
Gdyby ktoś chciał poczytać więcej o tym bugu, zapraszam
tutaj.
WIDGETIZE