zmaten z gcc, glibc...

Milan Kerslager milan.kerslager na spsselib.hiedu.cz
Úterý Srpen 28 13:47:41 CEST 2001


On Tue, 28 Aug 2001, Ing. Pavel PaJaSoft Janousek wrote:

> > 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).
>
> Promin, ale to je hodne velka hloupost, co jsi prave napsal, muzes mi
> rici, proc by se aktualni rekneme sendmail (opravdovy dinosaurus
> pamatujici 70. leta) nemohl prelozit jak na novych platformach, tak na
> treba Minixu? (paklize, je minix supported platform)

Pokud vim, tady se probiral problem ze neci aplikace nejde prelozit.
Sendmail je (i historicky) psany tak, aby sel prelozit na nejruznejsich
systemech. Podle toho vypadaji take skripty, ktere se pred zahajenim
kompilace pouzivaji.

Pokud by neci program byl napsan jako sendmail, tak nemame zadny problem.
Jenze zdejsi diskuteri poukazuji prave na sve produkty (ktere tak napsane
nejsou a tudiz nejdou prelozit v nadchazejicim prostredi GCC 3.0.x a Glibc
2.2, ktere je dostatecne presne reprezentovano soucasnym stavem v RH).

> > uvedomte si, ze stare kompilatory podporuji zpusob psani kodu tak, jak to
> > uz *nikdy* nebude podporovano. Pokud dnes nejde nekomu prelozit neco na
>
> To je zase blbost, pokud mluvime o C, vazne nevim o cem mluvis, pokud o
> C++, pak norma (udajne, jeste jsem jeji zneni nevidel a paltit ji
> nehodlam) jeste nema zaschly inkoust, tudiz co se delalo dle jak rikam
> prumysloveho standardu (zpravidla prekladac AT&T verze 2.0), je mozna k
> nicemu, holt vyhoda proprietalnich reseni...
>
> >     kompatibilita se porusuje kazdych cca 1.5 roku u vsech distribuci
> >     vzdy prechodem na vyssi major verzi)
>
> 	A to tedy znamena ze kazde 2 roky minimalne musim provest komplexni QA
> pro muj produkt, tomu rikas nasazeni pro Enterprise oblast? Mam pocit,
> ze ani netusis o co v ni jde predevsim...

Ne, prave ze ne. Protoze kod programu prelozitelny pomoci GCC 2.96 bude
vypadat stejne (nebo 99,9% stejne) jako pro GCC 3.0.x, mohl (kdokoliv) uz
nyni (resp. od lonskeho podzima) s timto kompilatorem pracovat (bohuzel na
nej nekteri jen nadavaji) a pripravovat se tak snadno na (pravdepodobne
delsi) obdobi jistot kompilatoru GCC 3.0.x (tj. prodlouzit si obdobi, kdy
se s aplikaci nebude muset hybat).

Taky jsem psal, ze distribuce obsahuji compat-* balicky, takze obdobi, kdy
lze v pohode vyuzivat jedny knihovny, se razem prodluzuje na 3 roky
(vlastne ale na 4.5, pokud uvazime, ze predchozi rada je v oficialni
podpore jeste behem cele rady nasledujici, tj. dnes je podporovana porad
jeste rada RH 6.x, coz znamena i Glibc 2.0 z RH 5.x pomoci compat-*
balicku), coz uz neni tak malo.

Zcela evidentne je tedy problem v nedorozumeni. NIKDO nikoho nenuti
pouzivat pro svuj vyvoj GCC 2.96. Existuji jednoducha a prima reseni na
vsechno, na co se tady nadava. Jen je potreba trochu uvazovat a uvedomit
si, ze vyvoj Linuxu je z principu spojity a nikdo ho nezastavi (taky proc,
ze jo) a brecet na spravnem hrobe.

Jiste, v pripade, ze chcete vydrzet 5 let na stejnych knihovnach, musite
tomu podridit i styl vyvoje sveho produktu. Pokud nechcete nebo nemuzete
zustat u jednech knihoven, musite se smirit s rychlejsim vyvojem a zase se
prizpusobit (a ne tvrdit, ze za Vase problemy muze RH). Taky nesmite
vyuzivat postupy, ktere jsou vazany presne k nektere verzi knihovny (jak
to treba delal StarOffice) nebo k jejim internim zalezitostem.

Pro jistotu tedy zopakuji, ze jsem tady vystupoval proti nadavkam, ktere
smerovaly nespravnym smerem a snazil jsem se upozornit i na to, ze uvedene
"nedostatky" mohou byt dokonce prednostmi (zalezi na uhlu pohledu a na
vstupnich pozadavcich) a take na to, ze reseni problemu existuje (tj. ze
nadavky jsou zbytecne).

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



Další informace o konferenci Linux