rh 7.0, gcc a problemy

[Milan Kerslager]

On Wed, 3 Jan 2001, Libor Chocholaty wrote:

> Doporucuju si precist:
>  http://www.linuxworld.cz/lw.nsf/page/F4A16C55C6442031C12569B9002F7CF0

Napsal bych tam reakci, ale nejde to (je to nejake rozbite).

Ten clanek je silne jednostranne vedeny v duchu uz zde prezentovaneho
sporu s kolegou Janikem.

Ani po podani vycerpavajicich argumentu proc to tak neni a proc nema
pravdu (tedy spise ze neumi uznat protiargumenty druhe strany a na vsechny
vypady existuji vyznamne 'ale'), bude snad jeste nekolikrat omilat toto
tema.

Vyjadrim se radeji jen ke zminenemu clanku, abych se porad neopakoval.

1) distribuce obsahovala "neposveceny" snapshot GCC (2.96)
   - tohle neni argument. Posledni zhruba dva roky se bezne pouzivaji
     CVS snapshoty cehokoliv. Od XFree pres KDE k dalsim i obycejnejsim
     nastrojum. Dela se to proto, ze v CVS jsou obvykle patche na zname
     chyby. Cislo verze si nikdo nevymyslel, bylo normalne zavedeno
     v aktualnim CVS.
   - vsechny (cca 80) patche pro GCC 2.96 z CVS byly po vydani RH prijaty
     GCC teamem, ktery pak oznamil, ze zvysi oznaceni na 2.97 (tj. v RH je
     technicky spise skoro 2.97 nez 2.96)
   - opravy se delaly zejmena pro Glibc a ne pro kompilator (ale opravy
     se delaji porad a na vsechno, takze se nemusime divit - spis bychom
     meli byt spokojeni, ze se bugreporty nezametaji pod koberec)
   - pro nas pro vsechny je lepsi, kdyz se pouziji nove komponenty,
     protoze latani starych je neproduktivni stejne jako vyroba
     tisice zaplat. V novem RH bude novy kompilator, pouze se bude
     udrzovat binarni kompatibilita (pokud se pro novejsi GCC zmeni)
     Tim se usetri uzivatelum jeden krok v binarne nekompatibilnich
     balicich (musel by se pouzit mezikrok, ktery by stejne porusil
     binarni kompatibilitu s radou 6.x, takze se jeden usetril).
   - je videt jasna tendence k pouzivani noveho kompilatoru a pokud
     by ho distribuce uzivatelum neposkytla, omezovala by je, protoze
     je funkcni. Novy kompilator je lepsi volbou, nez vsechny predchozi.

2) distribuce obsahuje prekladac kgcc pro preklad jadra
   - prakticky vsechny distribuce pouzivaji pro preklad jadra jiny
     prekladac, nez pro normalni programy. Je to zpusobeno tim, ze
     jadro je velmi citlive na jeho zmenu a neni mozne vse jednoduse
     otestovat (zejmena vsechny moduly)
   - v tomto ohledu je kritika vety "nejde mi prekladacem XY prelozit
     jadro" irelevantni, protoze se vztahuje na *vsechny* distribuce,
     ktere pouzivaji zvlastni kompilator (prakticky vsechny distribuce)

3) Linux kritizuje Red Hat za pouziti gcc 2.96
   - tohle Linus prehnal a posleze pozadal o zasilani patchu, ktere
     prizpusobuji jadro pro tento prekladac. Nasledujici verze prekladace
     budou pokracovat udanym smerem a *nebudou* se prizpusobovat jadru
     (jiste, kazdy prekladac obsahuje chyby - proto se jadra prekladaji
     overenymi starymi verzemi a zadny novejsi kompilator se nepouziva
     zejmena pro radu 2.2.x)
   - kompilator gcc 2.96 neni kompletne 'broken'. Po roce testovani a
     vyvoje, kteremu se RH team venoval, je jim prelozena cela distribuce
     bez nutnosti vyrabet backporty na nove verze programu (aby byly
     kompilovatelne starsimi kompilatory). Linus povazuje za 'broken'
     kompilatory podle toho, zda prelozi jadro, ale to neprelozi zadny
     kompilator soucasnych distribuci (mini se 100%, v urcitych pripadech
     to muze fungovat i s novejsimi)
   - kompilator se nebude downgradovat, protoze by pak nebyl schopen
     prekladu ostatnich programu v distribuci (zdrojaky jadra tvori
     velmi male procento vsech zdrojaku v distribuci a nedovedu si
     predstavit, ze by nekdo vyrabel (!zbytecne!) tisice zaplat tak,
     aby vse slo kompilovat pomoci 'non-broken' kgcc
   - gcc 2.96 je jediny kompilator, ktery nema problemy s kompilaci
     vsech programu v distribuci a zaroven jejich kompilaci pro jine
     platformy (Sparc, Alpha), je tedy vyrazne jednoticim prvkem
     a spravnou volbou (take nejlepe podporovatelnou a nejlepe
     udrzovatelnou).
   - RH neobsahuje 'broken libraries', obsahuje oficilani verzi
     Glibc 2.2. 'Broken' jsou blbe napsane aplikace (par jich je).
     Je lepsi opravit aplikace, nez pouzivat stare knihovny.
   - podobne vylevy jsem od Linuse cetl uz mnohokrat (na adresu vsech
     kompilatoru) a ani tenhle nevybocuje z rady

4) Roztrzka nad balikem modutils
   - vyvojar modutils si stezoval, ze s nim RH nespolupracuji a ze
     s jinymi distribucemi ma lepsi vztahy. Stezoval si zejmena na to,
     ze RH nedodava svoje patche. Bohuzel nadaval na patch, ktery mu nekdo
     z RH poslal (takze prece jenom nejake dostava). Patch vracel zmeny
     zpusobene prejmenovanim prepinacu, coz ho rozzurilo. Uvedeny patch
     vzniknul proto, ze v RH se pouziva jiz dele jadro 2.4 (na zkousku)
     a jsou k nemu potreba nove modutils. V oficialni distribuci ale je
     jadro 2.2 a neni jednodussi reseni, nez tohle. Neni mozne najednou
     uzivatelum jadra 2.2 predhodit neco, co neni kompatibilni s
     predchozim stavem i kdyz jadro je stejne.


Rozpadani Open Source zpusobi spise neochota domluvit se, naslouchat
argumentum protistrany a videt veci v sirsich souvislostech, nez pouziti
zdrojaku z CVS.


Dalsi poznamky o tom, ze GCC nebude binarne kompatibilni s verzi 3.0 a
dalsi podobne nesmysly (nebo to jsou jen ucelove nepresna tvrzeni?) jsem
podeprel argumenty uz drive a lze je najit v archivu konference. Zkracene
se to da popsta tak, ze binarni kompatibilita na urovni jazyka C bude
zachovana o kompatibilte na urovni C++ se neda mluvit, protoze standard
jeste neni a neni jiste kdy bude (a tedy zda bude zachovan soucasny stav
nebo budou provedeny nejake dilci zmeny).

Urcite jsem na neco zapomel, ale skutecne me to neustale omilani unavuje.
Predpokladal jsem, ze jsme si to uz vysvetlili...., ale asi jsem se mylil.

-- 
                        Milan Kerslager
                        E-mail: milan.kerslager na spsselib.hiedu.cz
                        WWW:    http://www.spsselib.hiedu.cz/~kerslage/