zmaten z gcc, glibc...

[Milan Kerslager]

On Tue, 28 Aug 2001, Stanislav Meduna wrote:

> >BTW: je uplne normalni, ze kazda komponenta v systemu potrebuje jiny
> >     kopilator nebo zaplaty k tomu, aby sla prelozit s knihovnami X.Y.Z.
>
> Jezisikriste, ak toto je "uplne normalni", tak cely Linux mozme zabalit
> a vratit sa k Microsoftu.

Zkuste si nekdy prelozit nebo provozovat nejaky produkt pod starsi verzi
Linuxu. Nepujde to. Je to proste tak. Linux != na-veky-stejny. Ale mame
zdrojove kody. Vzdycky to tak bylo a nekompatibilita vzdy bude (uz z
duvodu pouziti rozdilnych komponent) a vsichni se snazi, aby byla co
nejmensi (ovsem stav kompilatoru za poslednich 5 let to neumoznuje).


Panove,

uvedomte si, ze stare kompilatory podporuji zpusob psani kodu tak, jak to
uz *nikdy* nebude podporovano. Pokud dnes nejde nekomu prelozit neco na
2.96, nepujde mu to s velmi velkou pravdepodobnosti prelozit ani na
novejsich kompilatorech (tyka ze zejmena C++, ponechme stranou chyby
kompilatoru, ktere se daji opravit a jsou i ve starsich verzich).

To je _realita_. Vsichni budou svuj kod *muset* prizpusobit novemu
kompilatoru a je lhostejne, zda to udelaji uz ted, zitra nebo za rok (tj.
jestli na tom zacnou pracovat uz ted nebo se na to zatim vykaslou). RH
umoznuje vsem, aby sve produkty prizpusobili a pripravili se na
budoucnost. Nikde neni napsane, ze produkt X.Y uz *nyni* musi fungovat na
nove Glibc a byt prelozitelny poslednimi kompilatory (ale dojde k tomu).

To, ze nejsou nejake aplikace prelozit na novem kompilatoru znamena, ze
jejich vyvojari jeste neopravili svuj kod. Pro to, co je v distribuci, to
udelali sami tvurci distribuce. Nelze predpokladat, ze RH bude produkovat
patche pro produkty, ktere vytvareji jine firmy a nelze predpokladat, ze
nove verze kompilatoru se budou opravovat tak, aby schroupaly kod napsany
podle jiz neplatnych pravidel (nebo podle pravidel, ktere obchazeji chyby
starsich kompilatoru).

Ohanet se na tomto miste "mnoha vyvojovymi platformami" je nelogicke,
protoze se opravdu vse presune k novemu kopilatoru, ktery je proste JINY,
nez ty stare a BUDE se pouzivat at se to nekomu libi nebo ne a API je
proste jine.

Verze 2.96 mela ukonceny vyvoj API (tj. podobu zdrojoveho kodu). Ukoncen
nebyl byvoj ABI pro C++ (binarni podoba). Kdyz je neco zverejneno CVS, je
obvykle, ze se kod v nem ulozeny pouziva. Pokud s tim tvurci projektu
nesouhlasi, maji pravo deklarovat, ze nebudou tuto verzi podporovat (to
udelali), ale je velmi neobvykle branit nekomu kod v CVS pouzit (nedavno
zde byla prave diskuze o tom, ze k tomu CVS slouzi a ze by to pomohlo
vyvoji jadra - Linus ani jini nikdy neprotestoval proti pouzivani
"meziverzi", protoze dulezity je vysledek a ne z ceho je to slozeno - tj.
je lepsi, kdyz se pouzije stabilni meziverze, nez aby se pouzila
nestabilni verze oznacena jako stabilni [vzpomente si, jak se zde nadavalo
na to, ze vsechny verze x.0 jsou uplne naprd]).

V RH bude jako alternativa kompilator 3.0, ktery uz vysel. Protoze 2.96
neni pro C++ kompatibilni s 3.0 (to se vedelo uz na podzim). Takze
soucasny kompilator v RH prebira z 3.0 upravy, ktere binarni kompatibilitu
nenarusuji.

Zaroven RH obsahuje balicky pro zpetnou kompatibilitou pro starsi
kompilatory a starsi knihovny. Proc je tedy nepouzijete a nadavate na novy
kompilator? To jsou stiznosti na nespravnem miste.

Duvody pro volbu verze 2.96 jsou sepsany zde:

http://www.lwn.net/2000/1005/a/rh-tools.php3

Strucne shrunuto:
  - 2.96 pracuje i na jinych platformach bez zvlastnich uprav
  - posledni stabilni kompilator 2.95.2 je nekompatibilni dolu i
    nahoru, takze binarni kompatibilitu pro radu 7.x nelze mezi
    6.x a 8.x zadnym zpusobem zachovat
  - GCC 2.96 je na urovni zdrojoveko kodu kompatibilni s 3.0.
    To neplati pro binarku, ale to neni fatalni (binarni
    kompatibilita se porusuje kazdych cca 1.5 roku u vsech distribuci
    vzdy prechodem na vyssi major verzi)
  - je lepsi venovat potencial svych vyvojaru na neco noveho a
    prinosneho, nez na produkci fixu pro stary kompilator
  - binarni kompatibilita musela byt stejne porusena, protoze
    rada 6.x pouzivala velmi stary kompilator (egcs-1.1.2)
    RH nikdy nemel 2.95.2 a protoze 2.96 je na urovni zdrojaku
    kompatibilni s 3.0, je vyhodnejsi vyhnout se produkci zbytecnych
    zaplat, protoze prelozeni programu neodebira produktivni
    cinnost vyvojarum.


K poslednimu dotazu: ano, venuji se vyvoji distribuce od roku 1996, kdy
jsem si zacal delat svoji vlastni distribuci a snazil jsem se drzet sam o
sobe vlastni vyvoj az do dnesniho data (v ruznych formach a v ruznem
rozsahu). Vim presne, co znamena neco vydat, delat udrzbu, shanet zaplaty,
psat vlastni, reportovat chyby, uznat svoje chyby, vim co znamena zvazit
vyhody a nevyhody vlastnich rozhodnuti, smirit se a akceptovat
rozhodnutimi jinych, delat podporu a dostatecne je mi znamo, co znamena
udrzet prehled nad zvlastnostmi vsech komponet v systemu (tj. vzajemne
nekompatibility nebo vzajemne pozadavky ruznych casti systemu). Zucastnuji
se aktivne testovani distribuce RH, delam preklady a delam to ve svem
volnem case. Delal jsem sve vlastni SW projekty, spolupracoval jsem i na
jinych projektech. Pri sve praci jsem musel integrovat ruzne programy,
ruzne verze a ruzne pohledy na vyvoj. Nikomu neupiram pravo na jeho
vlastni nazor na vedeni projektu, ale neuznavam, kdyz neplati ani obracene
pravidlo (tj. ja mam sve duvody, sva rozhodnuti a jsem za ne zodpovedny
minimalne sam sobe a nemusim akceptovat cizi nazory, pokud se s nimi
neztotoznim).

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