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 :P 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.