# Gcc-4.1.1 - czy aby naprawde stable ?

## Yatmai

Dziś w portage zauważyłem, że gcc-4.1.1 dostało keyword'a stable. Pytanie do tych, co gcc w wersji 4 używają w praktyce... Czy aby napewno poprawiły sie problemy z niektórymi kompilacjami ?  :Smile: 

----------

## adam1957

Witam!

Od pewnego czasu [ok 3 mc-e] kompiluję gcc-4.1.1 i nie narzekam. W zasadzie bez wpadek.

----------

## manwe_

Cały system postawiłem na 4.1.x [chyba jeszcze .0] i żadnych problemów. Wersję 3.4.6 trzymam "a nuż się przyda" oraz dla audacious i audacious-docklet [nie lubią gcc4 pod amd64].

----------

## Odinist

Dziś w nocy przekompilowałem system z gcc-4.1.1 (564 pakiety) i co zauważyłem:

- app-emu/uae nie kompiluje się pod gcc-4.1.1

- dev-libs/boehm-gc musi być odmaskowany (6.7) żeby nie wywalało błedu podczas merdżowania

- aMule wywala bład przy próbie pobrania listy z serwerów z domyślnej lokalizacji

I to tyle, więc jest dobrze   :Razz: 

I pytanie: Czy podczas przechodzenia z gcc-3.X na gcc-4.1.1 trzeba wyczyścić temp ccache  :Question: 

----------

## Arfrever

Używam GCC 4.1.1 od kilku miesięcy, wcześniej używałem m. in. GCC 4.1.0. Nie mam żadnych problemów z GCC.

 *-Nile- wrote:*   

> I pytanie: Czy podczas przechodzenia z gcc-3.X na gcc-4.1.1 trzeba wyczyścić temp ccache 

 Nie trzeba, ale opłaca się, bo kompilator już nigdy nie wykorzysta zawartości cache pochodzącej z czasów GCC 3.*. Lepiej usunąć te śmieci.

Sveikinu

Arfrever

----------

## yoshi314

mnie wkurza jedno - qemu . byly patche do 0.8.1 na gcc4. dzialalo. 

wyszlo 0.8.2 - nie kompiluje sie na gcc4. mozna odniesc wrazenie ze autor chyba ma cos za zle gcc4 :]

----------

## mziab

Cieszę się, że ktoś w końcu założył taki topic. Noszę się z zamiarem przejścia na nowe gcc, ale podchodzę do tematu ze sporą ostrożnością. Przestudiowałem już całe mnóstwo materiałów dotyczących nowego kompilatora. Zawsze jednak lepiej usłyszeć jak to jest w praktyce. Pozwólcie więc, że zadam parę pytań.

Przede wszystkim, czy to prawda, że gcc 4.1 przynosi znaczny wzrost szybkości kompilacji? Według niektórych głosów kompilacja może być szybsza o prawie połowę. Ktoś może to potwierdzić? Byłoby miło, gdyby była to prawda, chyba przyznacie  :Smile:  Poza tym, jak się ma w prkatyce prędkość działania kodu wygenerowanego przez nowe gcc?

Po drugie, załóżmy, że będę chciał przerwać rekompilację systemu, by wyłączyć komputer na noc. Czy to aby na pewno bezpieczne? Jakie są szanse, że po takiej przerwie system nie będzie się nadawał do użycia? Czy moje obawy są bezpodstawne?

----------

## Arfrever

 *mziab wrote:*   

> Po drugie, załóżmy, że będę chciał przerwać rekompilację systemu, by wyłączyć komputer na noc. Czy to aby na pewno bezpieczne? Jakie są szanse, że po takiej przerwie system nie będzie się nadawał do użycia? Czy moje obawy są bezpodstawne?

 

Zawsze można użyć LiveCD, chroot i kontynuować przebudowę systemu. Przed wyłączeniem komputera pamiętaj o `etc-update`.

A najlepiej włączyć hibernację.

Sveikinu

Arfrever

----------

## bartmarian

to chyba bardziej chodzilo o pytanie, co sie stanie jak sie kompilacja jednak przerwie,

a czesc systemu bedzie miala stare binarki a czesc nowe, nie wiem noo... pradu zabraknie  :Wink: 

a powazniej to stoje przed wyborem czy aktualizowac gcc-4.1.1 serwer, na ktorym

mam spoooro... lepsze wrogiem dobrego, wiec mam obawy ale i swierzbi  :Wink: 

----------

## Odinist

Zawsze możesz kontynuować przerwaną rekompilację systemu 

```
# emerge --resume
```

----------

## mziab

Wiem, że można wznowić kompilację. Nie o to mi chodziło. Chcę po prostu wiedzieć czy, gdy już zacznę przebudowywać system, dla bezpieczeństwa nie wyłączać komputera na noc. Wyraziłem się wystarczająco jasno?  :Smile:  Krótko mówiąc, czy kompilowanie na raty szkodzi? Dzięki, bartmarian, że chociaż ty jeden zrozumiałeś  :Smile: 

----------

## bartmarian

tak sie zastanawialem, i chyba na dobra sprawe nikt nie bedzie wiedzial (a moze bedzie) czy pomieszanie binarek

bedzie grozilo katastrofa, najpierw zrobie dasktopa, jak bedzie ladnie smigac, to wezme sie za serwer,

natomiast nie bede testowal przerywania - chyba ze nie bede mial innego wyjscia...  :Smile: 

(z drugiej strony przejscie z 3.2 na 3.4 przebudowalo mi 3/4 systemu, czyli jakies 750 z 1000 "pakietow",

potem "cos" tam sie nie chcialo skompilowac, i w sumie dalem sobie spokój/czasu nie bylo/inne i tak zostawilem...

..::Milu Edit: ort!

----------

## kicior

 *bartmarian wrote:*   

> potem "cos" tam sie nie chcialo skompilowac, i w sumie dalem sobie spokuj/czasu nie bylo/inne i tak zostawilem...

 Wtedy dawaj

```
emerge --resume --skipfirst
```

i niech leci dalej.

----------

## vanbastek

Ja otzrymałem od dobrego człowieka stage3 przygotowany na gcc 4.1.1. Wersję 3.4.6 wyrzuciłem, wszystko robie na 4 i nie mam problemów, teraz mi sie qemu zachciało i jednak bedę musiał 3 z powrotem zainstalować.

----------

## grodzik86

Dzisiaj skonczylem "emerge -e world" przy uzyciu gcc 4.1.1(823 pakiety na amd64) i wystapil tylko jeden blad w trakcie kompilacji fbset. Po "emerge --resume" blad sam zniknal ;/  A teraz przegladam przy uzyciu genlop-a czasy kompilacji roznych programow i widze, iz zdaza sie znaczna poprawa czasu kompilacji  :Smile:  , tylko przy KDE czas kompilacji sie wydluzyl

Pozdrawiam,

grodzik

----------

## mziab

grodzik86: Podzieliłbyś się tymi konkretnymi liczbami? Chętnie bym zobaczył o ile szybciej to cudo kompiluje  :Smile: 

----------

## grodzik86

A podziele sie.

Tutaj sa porownania na korzysc gcc 4.1.1

A tutaj na korzysc gcc 3.4.6-r1

Korzysci sa, ale sa tez i straty(niektore spowodowane dodatkowymi flagami USE)

Nie zauwazylem tez, zeby jakos specjalnie szybciej mi sie cos uruchamialo, chociaz moze KDE jakies troszeczke szybsze jest

Pozdrawiam,

grodzik

----------

## mziab

Zdecydowałem się jednak przekompilować system używając nowego kompilatora. Ogólnie nie jest źle. Podczas emerge -e world kompilacja wywaliła mi się jak na razie w dwóch miejscach, w tym na jednym ebuildzie z overlaya. W drugim przypadku bodajże xkbcomp zażądał ręcznego usunięcia jednego katalogu.

Jeśli chodzi o prędkość nowego kompilatora, moje uczucia są mieszane. Na ogół wszystko kompiluje się mniej więcej tak samo długo jak na gcc 3.3.6, chwilami trochę wolniej. Najbardziej spektakularny wzrost wydajności doświadczyłem przy qt3:

 *Quote:*   

> Mon May 22 14:29:04 2006 >>> x11-libs/qt-3.3.6-r1
> 
>       merge time: 53 minutes and 13 seconds.
> 
>     Wed Sep  6 01:30:31 2006 >>> x11-libs/qt-3.3.6-r1
> ...

 

Warto przy okazji zauważyć, że genlop bierze też pod uwagę czas ściągania źródeł. Jednak na moim łączu byłoby to najwyżej 7 minut.

Przy okazji, jeśli by ktoś był zainteresowany, przerobiłem nieco skrypt Poe do kompilowania world na raty. Teraz w razie błędu przerywa pracę zamiast kompilować następny pakiet.

Oto on:

```
#!/bin/bash

while true

do

        PAKIET=`head -n 1 file.lst`

        if [ -z "$PAKIET" ]; then

                exit 0

        else

                emerge --oneshot $PAKIET || exit 1

                grep -v "$PAKIET" file.lst > file.ls1

                mv file.ls1 file.lst

        fi

done
```

Stary przepis na generowanie listy się trochę zdezaktualizował, bo portage podczas emerge -ep world wyświetla teraz flagi USE, które uległy zmianie. Nowy przepis na wygenerowanie tego pliku to:

```
emerge -ep world|cut -d] -f2|cut -d" " -f2 | grep / | grep -ve "\-\(bin\|sources\)-" | sed -e 's/^/=/' >file.lst
```

Przepis jest oparty na znalezionym przeze mnie w jednym z topiców o gcc4. Przy okazji pozwoliłem sobie odfiltrować pakiety *-bin i *-sources, bo ich "rekompilacja" jest niepożądana i niepotrzebna. Poprawcie mnie, jeśli się mylę  :Smile:  Format listy zmienił się o tyle, że teraz każdy wpis poprzedzony jest znakiem równości. Zrobiłem to, by ułatwić sobie życie, gdyby zaszła potrzeba odmaskowania któregoś z pakietów. Teraz pod odmaskowaniu w package.keywords wystarczy zmienić w file.lst =foo-bar/oof-wersja na foo-bar/oof (bez znaku równości) i po wznowieniu działania skryptu instaluje się odmaskowana wersja.

----------

## Gabrys

Też odniosłem wrażenie, że się szybciej teraz kompiluje. Kiedyś Firefox się kompilował całą wieczność, teraz ledwo wyszedłem na obiad, wróciłem i już był gotowy.

Kompilacja niestety się przerywa tu i ówdzie mimo safe cflags, to mnie trochę niepokoi, ale co zrobić. Np. przy evolution.

Zauważyłem, że sterowniki rtl8180-sa2400 z CVS kompilują się, ale zawieszają system, gdy kompilowane na GCC4. Miałem do wyboru dwie drogi:

* jądro 2.6.18 na GCC 3.4.6 + sterowniki rtl8180-sa2400

* jądro 2.6.17 na GCC 4.1 + ndiswrapper

Cokolwiek bym nie wybrał, zawsze źle.

----------

## tomekb

No i jeśli ktoś używa KDE, to wielką zaleta przejścia na gcc-4.1 jest możliwość włączenia tej flagi:  *Quote:*   

> kdehiddenvisibility - Makes KDE symbols hidden by default, requires GCC 4.1 (experimental)

 

I żadna tam ona "experimental"  :Wink:  Ja jestem pod wrażeniem szybkości KDE skompilowanego przy użyciu tego. Po starcie razem z konsole zajmuje mi ~40 MB ramu, przy ~67 MB w wypadku GNOME.

----------

## Belliash

 *grodzik86 wrote:*   

> A podziele sie.
> 
> Tutaj sa porownania na korzysc gcc 4.1.1
> 
> A tutaj na korzysc gcc 3.4.6-r1
> ...

 

Cos klamiesz wac pan  :Wink: 

```
GCC 4.1.1:

Sat Sep  2 18:16:46 2006 >>> kde-base/kdebase-3.5.4

merge time: 1 hour, 14 minutes and 32 seconds.

GCC: 3.4.6:

Mon Sep  4 17:28:23 2006 >>> kde-base/kdebase-3.5.4

merge time: 1 hour, 19 minutes and 24 seconds.
```

Dodaj se --as-needed i -Bdirect do LDFLAGS oraz -ftree-vectorize do CFLAGS, skompiluje GCC 4.1.1 pod GCC 4.1.1, oprzyj wszystko na GlibC 2.4, to moze Ci przyspieszy...

----------

## Yatmai

Po przebudowaniu przyznam, że gcc-4.1 + --as-needed w ldflags + oc procka dało niezłegko kopa. Configure z emerge'a zasuwa nieziemsko, KDE wydaje sie jakby lżejsze... Problem tylko w tym, że miałem troche cyrków i przerwań kompilacji; tu sie nie podobało --as-needed, tu gcc-4.1, tu jeszcze coś... 

Eh, jak sie naciesze przyspieszeniem, to postawie w końcu na drugiej partycji system 64bit  :Very Happy: 

PS -ftree-vectorize daje to "dużo" ? (czytaj odczuwalnie ?  :Very Happy: ) bo po za tym jednym mam całą resztę  :Very Happy: 

----------

## Gabrys

 *tomekb wrote:*   

> No i jeśli ktoś używa KDE, to wielką zaleta przejścia na gcc-4.1 jest możliwość włączenia tej flagi:  *Quote:*   kdehiddenvisibility - Makes KDE symbols hidden by default, requires GCC 4.1 (experimental) 
> 
> I żadna tam ona "experimental"  Ja jestem pod wrażeniem szybkości KDE skompilowanego przy użyciu tego. Po starcie razem z konsole zajmuje mi ~40 MB ramu, przy ~67 MB w wypadku GNOME.

 

Zapomniałeś powiedzieć, że gryzie się z prelinkiem. Przynajmniej tak czytałem w CFLAGS matrix, że -fcośtamhiden-visibility się gryzie z prelinkiem.

----------

## n0rbi666

 *Gabrys wrote:*   

> Zapomniałeś powiedzieć, że gryzie się z prelinkiem. Przynajmniej tak czytałem w CFLAGS matrix, że -fcośtamhiden-visibility się gryzie z prelinkiem.

 Mam kdehiddenvisibility w USE, mam -fvisibility-inlines-hidden w CXXFLAGS, używam prelinka - i nie widzę żadnych problemów  :Smile: 

----------

## Yatmai

Ja mam -fvisibility-inlines-hidden właśnie dołożylem prelinka.... Co prawda KDE już mi nie przyspieszyło (bo już fizycznien nie ma jak -> start 3-5s  :Very Happy: ) ale taki FF dopalil ostro  :Very Happy:  No i wszystko jak narazie działa  :Smile: 

----------

## n0rbi666

 *Art.root wrote:*   

> Ja mam -fvisibility-inlines-hidden właśnie dołożylem prelinka.... Co prawda KDE już mi nie przyspieszyło (bo już fizycznien nie ma jak -> start 3-5s ) ale taki FF dopalil ostro  No i wszystko jak narazie działa 

 

A masz w /etc/env.d/99kde-env :

```
KDE_IS_PRELINKED=1
```

Jka nie masz - dołóż, a potem env-update  :Smile: 

----------

## psycepa

u mnie nie kompiluje sie na 4.1.1-r1 tylko splashutils, ale nie chce mi sie narazie kombinowac z szukaniem rozwiazania  :Smile: 

pewnie jak zrekompiluje kernel to pojdzie bo cos tam sie plulo o krenel u_lont t czy cos takiego  :Smile: 

a tak to bez najmniejszych zastrzezen

pozdrawiam

----------

## Yatmai

 *n0rbi666 wrote:*   

>  *Art.root wrote:*   Ja mam -fvisibility-inlines-hidden właśnie dołożylem prelinka.... Co prawda KDE już mi nie przyspieszyło (bo już fizycznien nie ma jak -> start 3-5s ) ale taki FF dopalil ostro  No i wszystko jak narazie działa  
> 
> A masz w /etc/env.d/99kde-env :
> 
> ```
> ...

 

Już mam... Sądzisz, że można jeszcze przyspieszyć start KDE ?  :Very Happy: 

----------

## n0rbi666

psycepa - a masz gentoo-sources, czy coś innego ? 

jak coś innego, to :

- zemerguj gentoo-sources (pamiętaj o symlinku)

- emerge klibc

i teraz powinien przejść emerge splashutils  :Smile: 

potem można wywalić gentoo-sources  :Wink: 

----------

## psycepa

od dluzszego czasu, najpierw nitro, teraz beyond  :Smile: 

ale dzieki za rade, nie omieszkam sprobowac :>

----------

## mziab

Wczoraj zakończyłem migrację na nowe gcc. Poszło dość gładko, choć nie bezproblemowo. Głównie wykładało mi się na ebuildach z overlaya. Nie obyło się bez pisania własnych łatek. Musiałem odmaskować tylko 3 paczki: timidity++, avidemux i xvidcap.

Póki co nie żałuję swojej decyzji. Niektóre aplikacje otwierają się odczuwalnie szybciej. Przyśpieszenie kompilacji to jednak nie całkiem prawda. Jak pisałem wcześniej, jedyna rzecz, jaka wyraźnie szybciej się skompilowała to qt-3. Mimo sprawdzania genlop -t dla wielu popularnych i dużych paczek, nigdzie nie uświadczyłem podobnego przyśpieszenia.

----------

## milu

 *mziab wrote:*   

> Jak pisałem wcześniej, jedyna rzecz, jaka wyraźnie szybciej się skompilowała to qt-3. Mimo sprawdzania genlop -t dla wielu popularnych i dużych paczek, nigdzie nie uświadczyłem podobnego przyśpieszenia.

 

```
~ % genlop -t qt

 * x11-libs/qt

     Wed Apr 26 00:23:13 2006 >>> x11-libs/qt-3.3.6

       merge time: 14 minutes and 41 seconds.

     Thu Apr 27 14:58:03 2006 >>> x11-libs/qt-4.1.2

       merge time: 1 hour, 27 seconds.

     Thu May 11 14:24:05 2006 >>> x11-libs/qt-3.3.6-r1

       merge time: 14 minutes and 44 seconds.

     Mon May 29 16:27:24 2006 >>> x11-libs/qt-4.1.3

       merge time: 38 minutes and 41 seconds.

     Sun Jul  2 16:55:26 2006 >>> x11-libs/qt-4.1.4

       merge time: 30 minutes and 41 seconds.

     Thu Sep  7 13:00:02 2006 >>> x11-libs/qt-3.3.6-r1

       merge time: 15 minutes and 23 seconds.

     Thu Sep  7 23:49:03 2006 >>> x11-libs/qt-4.1.4

       merge time: 33 minutes and 59 seconds.

```

Tak wielką różnicę u siebie widzę tylko pomiędzy pierwszą kompilacją a kolejnymi. Nie wiem z czego dokładnie to wynika. Jednak pomiędzy wcześniejszym gcc a nowym różnica jest taka:

```
     Thu May 11 14:24:05 2006 >>> x11-libs/qt-3.3.6-r1

       merge time: 14 minutes and 44 seconds.

     Sun Jul  2 16:55:26 2006 >>> x11-libs/qt-4.1.4

       merge time: 30 minutes and 41 seconds.

     Thu Sep  7 13:00:02 2006 >>> x11-libs/qt-3.3.6-r1

       merge time: 15 minutes and 23 seconds.

     Thu Sep  7 23:49:03 2006 >>> x11-libs/qt-4.1.4

       merge time: 33 minutes and 59 seconds.

```

----------

## crocop

U mnie nowe gcc jest od kilku dni. Jak na razie nie mialem ani jednego problemu. Kompilacja i działanie systemu faktycznie na korzysc 4.1.1. Musze chyba jeszcze pomyslec nad --as-needed:)

----------

## psycepa

 *n0rbi666 wrote:*   

> psycepa - a masz gentoo-sources, czy coś innego ? 
> 
> jak coś innego, to :
> 
> - zemerguj gentoo-sources (pamiętaj o symlinku)
> ...

 

dzieki wielkie, podzialalo  :Smile:  pozdrawiam

----------

