# Fejlesztői panaszok

## GCC 2.96

### A háttér:

A GCC 2.95-ös sorozata egy hivatalos GNU kiadás és a GCC 2.95.3-as verziója a leghibamentesebb ebben a sorozatban. SOha nem tapasztaltunk fordítási problémákat, amik a gcc-2.95.3-ra lettek volna visszavezethetőek. A Red Hat Linux 7.0-tól kezdődően a Red Hat a GCC egy erősen patchelt CVS verzióját tette bele a disztribúciójába, és átnevezte 2.96-ra. A Red Hat azért vette bele ezt a verziót a disztribúciójába, mert a GCC 3.0 még nem volt kész abban az időben és szükségük volt egy fordítóra, ami jól működik a támogatott platformjaikon, beleértve az IA64-et és az s390-et. A Mandrake (most már Mandriva) követte a Red Hat példáját és elkezdte szállítani a GCC 2.96-ot a saját Linux-Mandrake 8.0 sorozatával.

### A helyzet:

A GCC csapat visszautasított bármiféle kapcsolatot a GCC 2.96-tal és kiadott egy hivatalos választ a GCC 2.96-ra. Sok fejlesztőnek problémái támadtak a GCC 2.96-tal és számos projekt, köztük az avifile, elkezdett más fordítókat javasolni. Érdekes link még a Linux kernel news flash a 2.4.17-es kernelről és a Voy Forum. Az MPlayer is szenvedett időszakos problémákkal, amik mind megoldódtak egy másik GCC verzióra való átállással. Számos projekt elkezdett "megkerüléseket" implementálni a 2.96 néhány hibájára, de mi nem vagyunk hajlandóak mások hibáit javítgatni, különösen mivel a javítások jelentősen rontják a teljesítményt.

A GCC 2.96 nem engedi meg a `|` (pipe) karaktereket az assembler kommentekben, mert támogatja mind az Intel, mind az AT&T szintaxisát és a `|` karakter egy szimbólum az Intel variánsban. A probléma az, hogy jelzés nélkül figyelmen kívül hagyja a teljes assembler blokkot. Ezt állítólag már javították, a GCC figyelmeztető üzenetet ír ki a blokk kihagyása helyett.

### A jelen:

A Red Hat azt mondja, hogy a GCC 2.96-85 és ez utániak javítva lettek. Az ügy közben tovább bonyolódott, még mindig találunk olyan hibajelentéseket a levelezési listáinkon, amik más fordítóval eltűnnek. Mindegy, a továbbiakban ez már nem számít. Remélhetőleg a készülő GCC 3.x megoldja ezt az ügyet. Ha mégis 2.96-tal akarsz fordítani, add meg a `--disable-gcc-checking` kapcsolót a `configure`-nak. Emlékezz rá, hogy ezesetben a magad ura vagy és ne jelents semmilyen hibát. Ha mégis ezt teszed, csak kitiltást kaphatsz a levelezési listáról, mert már a soknál is több flame volt a GCC 2.96 miatt. Pihentessük az ügyet.

Ha problémáid vannak a GCC 2.96-tal, letöltheted a 2.96-85 csomagokat a Red Hat ftp szerveréről vagy egyszerűen használd a 3.0.4 csomagokat, amik a 7.2 és későbbi kiadásokban találhatóak. Letöltheted a gcc-3.2.3-37 csomagokat is (nem hivatalos, de jól működő) és telepítheted a már meglévő gcc-2.96 mellé. Az MPlayer meg fogja találni és inkább a 3.2-eset használja a 2.96 helyett. Ha nem akarod vagy nem tudod használni a bináris csomagokat, itt van, hogy tudod lefordítani forrásból a GCC 3-at:

1. Menj a GCC tükröket tartalmazó oldalára és töltsd le a `gcc-core-XXX.tar.gz` fájlt, ahol XXX a verzió szám. Ebben benne van a teljes C fordító és elegendő az MPlayerhez. Ha C++, Java vagy valamelyik másik GCC funkció is kell neked, a `gcc-XXX.tar.gz` jobban megfelel az igényeidnek.

2. Csomagold ki az archívot a

       tar -xvzf gcc-core-XXX.tar.gz

   paranccsal!

3. A GCC nem a forrás könyvtárba kerül lefordításra, mint a legtöbb program, hanem kell neki egy kimeneti könyvtár valahol a forráson kívül. Így létre kell hoznod egy könyvtárat a

       mkdir gcc-build

   paranccsal.

4. Ezután elvégezheted a gcc konfigurálását a célkönyvtárból, azonban a configure a forrás könyvtárban van:

       cd gcc-build
       ../gcc-3.XXX/configure

5. Fordítsd le a GCC-t a következő parancs kiadásával a célkönyvtárban:

       make bootstrap

6. Most már telepítheted a GCC-t (mint root) a

       make install

   parancs begépelésével.

## Bináris disztribúciók

Az MPlayer régebben tartalmazott forrást az OpenDivX projektből, ami tiltja a bináris továbbadását. Ezt a kódot eltávolítottuk a 0.90-pre1 verzióban és a visszamardó `divx_vbr.c` fájlt, ami az OpenDivX forrásából származik, GPL terjesztés alá vették a fejlesztői a 0.90pre9-es verzióra. Így már nyugodtan készíthetsz bináris csomagokat, ha úgy tartja kedved.

A bináris továbbterjesztés másik akadálya a fordítási időben történő CPU architektúrának megfelelő optimalizáció volt. Az MPlayer most már támogatja a futásidejű CPU keresést (add meg az `--enable-runtime-cpudetection` kapcsolót a `configure` parancsnak). Alapértelmezésként ki van kapcsolva, mert magában hordoz egy kicsi sebességcsökkenést, de így most már lehetséges olyan binárisok létrehozása, amelyek futnak az Intel kompatibilis CPU család különböző tagjain.

## nVidia

Nem igazán örülünk annak a ténynek, hogy az nVidia csak bináris vezérlőt biztosít (az XFree86-tal történő használathoz), ami gyakran hibás. Rengeteg jelentést kaptunk az mplayer-users listán olyan problémákról, amik ezekhez a zárt forráskódú vezérlőkhöz kapcslódtak és ezek gyenge minőségéhez, instabilitásához és a felhasználói tapasztalatlansághoz. Sok ilyen probléma/dolog ismételten feltűnik. Nem régen tárgyaltunk az nVidia-val és azt mondták, hogy ezek a hibák nem léteznek, az instabilitást a rossz AGP chip-ek okozzák és hogy ők nem kaptak jelentést vezérlő hibákról (mint a rózsaszín vonal). Így ha problémád van az nVidia kártyáddal, azt tanácsoljuk, hogy frissítsd az nVidia vezérlőd és/vagy vegyél egy új alaplapot vagy kérd meg az nVidia-t, hogy biztosítson nyílt-forráskódú vezérlőket. Bármelyik esetben, ha az nVidia bináris vezérlőjét használod és vezérlő problémáid vannak, kérlek emlékezz rá, hogy tőlünk nagyon kevés segítséget kaphatsz, mert nincs elég energiánk, hogy az ilyen ügyekben is segítsünk.

## Joe Barr

Joe Barr 2001. decemberében lett elég népszerűtlen, amikor egy csöppet sem kedves MPlayer áttekintést készített, MPlayer: Projekt a pokolból címmel. Úgy találta, hogy az MPlayert nehéz telepíteni és azt a következtetést vonta le, hogy a fejlesztők barátságtalanok és a dokumentáció nem teljes valamint sértő. Légy te a bíró! Tovább menve negatívan tett említést Árpiról a 10 Linux predictions for 2002 című cikkjében. Egy következő áttekintésben, melyben a xine-ról ír A streaming media player for the rest of us címmel, folytatja a bajkeverést. Irónikus módon ezen cikk végén idézi Günter Bartsch-sal, a xine eredeti szerzőjével történt eszmecseréjét, ami tökéletesen összefoglalja az egész szituációt:

> Azonban kihangsúlyozta, hogy "meglepődött" az Mplayerről szóló írásomon és úgy gondolta, hogy az nem fair, emlékeztetve engem arra, hogy az is egy szabad szoftver projekt. "Ha nem szereted," mondja Bartsch, "szabad nem használnod."

Majdnem két évvel később, 2003. októberében írt egy másik áttekintést Mplayer revisited címmel (a hibás írásmódot megtartottam). Ebben az alábbi következtetésre jutott:

> Azt mondanám, hogy van fejlődés a jellemzők számát tekintve, teljesítményben, és a dokumentációban. Még mindig nem a világ legkönnyebb telepítése, különösen az újoncoknak, de kicsit jobb, mint régen.

és

> De ami még fontosabb, nem találtam semmilyen új, felhasználókat sértő megjegyzést. Úgy gondolom, ebben van egy kis részem, még akkor is, ha csak én gondolom így. Árpinak és a projekt többi tagjának is így gondolhatja, mert ügyeltek rá, hogy megemlékezzenek rólam a dokumentáció egy speciális részében, ami a tarball-ban is megtalálható. Mint ahogy az elején is mondtam, néhány dolog semmit sem változott.

Nem tudnánk ennél jobban összefoglalni a Joe Barr iránti érzéseinket: "Nem a legkorrektebb vagy legjobb utánajárás alapján megírt cikk a világon, de jobb, mint azelőtt volt." Talán a legközelebbi alkalommal már meg fogunk felelni egymás elvárásainak. Bár a beérésért járó köszönet csak az egyre múló időt illeti meg és talán az elfáradást a flame háborúkban.