zmaten z gcc, glibc...

[Pavel Kankovsky]

On Tue, 28 Aug 2001, Martin `MJ' Mares wrote:

> Hello, world!\n
> 
> > Ano, mas samozrejme pravdu, muzes mi vsak rici jediny argument, proc
> > nelze vytvorit interface, ktery byt nepredpoklada nejake nove
> > trendy/vlastnosti (neni na ne pripraven) by byl zpetne kompatibilni?
> 
> Zvlastni je, ze mne napadla presne opacna otazka: Je zde jediny duvod,
> proc by _mel_ jit takovy interface vytvorit? Svet okolo nas, ve kterem
> se snazime zit, se vyviji casto naprosto nepredpokladanym smerem a chceme-li,
> aby Linux byl v praxi pouzitelny, musi se umet existujicimu HW prizpusobit
> a vyuzivat jej co mozna nejefektivneji. At v interfacu zafixujeme temer
> cokoliv, muze se nam stat, ze casem tento invariant prestane platit.
> 
> Napadaji mne 3 cesty, jak se takovy problem da resit:

A pak mame jeste cestu 2.5, kde sice obcas interfejs menime, ale po
*urcitou dobu* (napr. 1 rok) zachovame v ramci moznosti pomoci "softwarove
redukce" kompatibilitu se starsi verzi rozhrani.

Tim se zaroven vyhneme Scylle neustaleho bobtnani (opravdu obsoletni veci
se likviduji), ale ani napadneme za obet Charybde prilis casto opakovanych
"velkych tresku", kdy se uplne vsechno musi *najednou* predelat, aby to
fungovalo.


On Wed, 29 Aug 2001, Ing. Pavel PaJaSoft Janousek wrote:

> 	Tak uz snad po ste... - zadna norma jazyka C++ se nemenila, ona
> __NIKDY__ zadna neexistovala! Vse co existovalo v nekolika verzich byl
> navrh normy v ramci pracovni standardizacni komise, ktera se k nemu
> vyjadrovala a pravdepodobne mela dost dobre duvody, proc delala zmeny
> mezi jednotlivymi draft verzemi normy [...]

Vskutku. I kdyz o dobrych duvodech nekterych zmen bych si dovolil
pochybovat (specialne se IMHO dost nesmyslnym zpusobem zmenily pravidla
pro pretypovani, ale to sem nepatri). Potiz je v tom, ze na te norme se
pracovalo tolik let, ze de facto standard AT&T uz mezitim natolik moralne
zastaral, ze asi neslo zaroven mit "pouzitelny" kompilator C++ a nesnazit
se do nej dostat nejak novinky.

Jina vec je, ze C++ je jazyk, ktery se naprosto utrhnul z retezu. Nedivil
bych se, kdyby mnozi lidi pracujici na kompilatoru skoncili v sanatoriu
pro dusevne destabilizovane jedince. :)

> pokud jsem zvolil spravny instrukcni soubor (I8086), nemam problem v
> prostredi MS DOS ci 'nastupnem' MS Windows takovyto program spustit
> (prosim, nechytat za slovo pri I/O spolupraci s periferiemi na urovni
> portu apod. -

Nahodou mam program, ktery pod MS DOSem funguje bez problemu, ale pod
Woknama spolehlive spadne (a 95-ky obcas posle do kytek kompletne).
A zadnym pristupem na porty to neni. Nastesti uz ten program nikdo
nepouziva, tak to uz nemusim resit. :)

> moc dobre vim, pokud jsou moje slova pravdiva).

Coze?!

> Takovato situaci, ktera je IMHO velmi potreba v ELF formatu (myslim,
> ze vychazi z COFF), bohuzel neexistuje... - pokud aplikaci skompiluju
> v RH 7.X, tezko ji spustim v RH 5.X ci jine distribuci starsiho data
> nez rekneme max. rok dozadu... - neni v necem chyba?

Za prve: ELF je hodne odlisny od COFFu. Za druhe: neni to problem ELFu.
Problem je zpusoben nekompatibilitou glibc a dalsich dynamickych knihoven
(coz lze vyresit statickym linkovanim a/nebo doinstalovanim alternativnich
dynamickych knihoven) a nevylucuji, ze jiste treci plochy mohou ve
specialnich pripadech vznikat i kvuli rozdilnym verzim jadra. Za treti:
to, ze neumite na RH 7.x zkompilovat program tak, aby fungoval na RH 5.x,
je Vase chyba. :)

> 	Drive slo zkompilovat veci ciste staticky a pak ani v UNIXech (pravda
> binarka mela radove MB a vice) nebyl problem - kolik knihoven je dneska
> dodavano tak, ze existuji obe alternativy?

Use the Source, Luke.

> > Kazda zmena minor verze meni rozhrani a je snaha je zachovat uvnitr
> > jednotlivych zaplato-verzi. Podle mych vzpominek to ale neni 100% pravidlo
> > a je to proste fakt.
> 
> 	No to je fakt s prominutim pekny bordel, jiz v drevnich dobach vyvoje
> software bylo nepsane pravidlo, ze takoveto zmeny jsou vysadou max. tzv.
> Major verze, minor slouzi predevsim k doladeni funkcnosti, opravam,
> zpetne kompatibilnimu rozsireni apod. - ne ke zmene rozhranni... mas
> jiny nazor?

Ovsem s timto je treba souhlasit. Je-li porusena kompatibilita, specialne
je-li porusena v obou smerech, tak je to duvod ke zmene major verze. Ovsem
mezi verzemi rozhrani (to jsou do jiste miry ta cisla, co jsou videt za
.so) a verzemi celych baliku panuje v dnesni dobe ponekud schizoidni stav.

--Pavel Kankovsky aka Peak  [ Boycott Microsoft--http://www.vcnet.com/bms ]
"Resistance is futile. Open your source code and prepare for assimilation."