A 64 fele 32, bitfaragás (még mindig)

(A téma – szokásomtól eltérően – nem lesz túl bő lére eresztve, leginkább jegyzet magamnak. Meg nem is how-to, ha valami kimaradt vagy nem jó a sorrend, értelemszerűen módosítandók a feladatok!)

Na de hogyan is kell 64 bites OS alatt 32 bitre fordítani? Ez első ránézésre Cross Compiling téma, de itt nem kéne annyira vészesnek lenni a helyzetnek, mivel a végeredményt is tudja futtatni az az OS, amin a forgatás készül. Legalábbis ez lenne a cél. Több fajta tippet találni internet szerte, hogy hogyan kell ezt a feladatot megoldani, a legtöbbjük 32 bites chroot környezetet javasol, de azért az húzósnak tűnik egy ilyen feladathoz.

A WINE-s „nyűgöm” keresése közben futottam bele ebbe az oldalba. Itt az látszik, hogy az rpmbuild tud x86_64 alatt i686-os csomagot is generálni, de a megfelelő paraméterrel (--target=i686) eddig még sehol sem találkoztam. De nem gondolnám, hogy chrootol, valahogy ezek szerint megoldható a feladat anélkül is. A linkelt oldal amúgy pont arról szól, hogy x86_64-es környezetben hogyan is kellene a WINE-t 32 bitesnek fordítani, de túl sok a csomag, ennek azt hiszem hogy nem ugranék mégse neki... :) De az FS-UAE egy kicsit konszolidáltabb ebből a szempontból.

Az oldalukon található dokumentáció alapján nem egy nagy kaland, van hozzá gyárilag .spec fájlt az rpmbuild számára, mi kellhet még? Ja, lelkesedés... :) A sima (x86_64-es) fordítással már megbirkóztam egyszer, kell neki néhány csomag a ”Fejlesztőeszközök” (”Development Tools”) csomagcsoporton kívül:

SDL-devel
freetype-devel
libpng-devel
glib2-devel
libX*-devel

Illetve kell még az openal-soft-devel csomag az EPEL-ből. Ezek persze felpakolnak függőségnek egyebeket is, de azok egy része is kell. (A libX*-devel közül nem volt türelmem kimazsolázni, hogy konkrétan mi szükséges.) Ezután egy sima

$ make

már le is fordítja, működik szépen. De ez az x86_64 verzió, ugye. Az i686-hoz ugyanezek a csomagok kellenének, (meg még néhány, ami x86_64-es verzióban alapból fent van,) de úgyszintén i686 verzióban. Mi van ezekből meg csomagban?

SDL-devel.i686
freetype-devel.i686
libpng-devel.i686
glib2-devel.i686
glibc-devel.i686
pulseaudio-libs-devel.i686
alsa-lib-devel.i686
libX*-devel.i686

Ez a lista impozáns, viszont az openal-soft-devel.i686 az biza hiányzik. Ebből saját csomagot leszek kénytelen gyártani... Ehhez először a forráscsomag kell:

$ yumdownloader --source openal-soft-devel

Ezt szét kell szedni:

$ rpm2cpio openal*.src.rpm | cpio -idmv

Ebből lesz egy .spec fájl, meg a forrás becsomagolva. Ezek fognak kelleni az újrafordításhoz. Az RPM generáláshoz ezeket a „helyükre” kell másolni:

$ mv openal-soft-* ~/RPMsandbox/SOURCES
$ mv openal-soft.spec ~/RPMsandbox/SPECS

Majd jöhet a csomagolási próba:

$ cd ~/RPMsandbox/SPECS
$ rpmbuild -bb --target=i686 openal-soft.spec

Na, innen kezdődik a dependency-hell, szerencsére csak diszkréten. :) Az openal-soft fordításához kell még a

pulseaudio-libs-devel.i686
qt-devel.i686
portaudio-devel.i686

Az első kettőből van kész csomag, de a portaudio-devel-ből nincs i686-os verzió, azt is forgatni kell, érzésre meg lesz vele valami nyűg. :)

$ yumdownloader --source portaudio
$ rpm2cpio portaudio*.src.rpm | cpio -idmv
$ mv pa_snapshot.tgz ~/RPMsandbox/SOURCES/
$ mv portaudio*.patch ~/RPMsandbox/SOURCES/
$ mv portaudio.spec ~/RPMsandbox/SPECS/
$ cd ~/RPMsandbox/SPECS/
$ rpmbuild -bb --target=i686 portaudio.spec

Ez persze nem készül el egyből, hiányzik a jack-audio-connection-kit-devel.i686, amiből úgyszintén nincs i686 csomag. Eh... Mondjuk maga a portaudio fordul enélkül is, csak akkor nem fog belekerülni a Jack támogatás. Ez most nekem nem lényeg, úgyhogy a .spec fájlban ki kell kommentezni egyrészt a BuildRequires: jack-audio-connection-kit-devel sort, hogy elinduljon a fordítás enélkül is, másrészt a %{_includedir}/pa_jack.h sort, hogy az RPM csomagolásánál se hiányolja a nem elkészült header fájlt. Persze még ezek után se akar fordulni, a hiba olyannak tűnik, mintha a linker x86_64-es bináris(oka)t szeretne csinálni i686-os bemenetből. A csomagolást „egy kicsit” meg kell támogatni a következő sorokkal:

$ export CC="gcc -m32"
$ export CXX="g++ -m32"
$ export CFLAGS="-march=i686"
$ export CXXFLAGS="-march=i686"
$ rpmbuild -bb --target=i686 portaudio.spec

Meglepő, de az RPMS/i686 könyvtárba elkészült három csomag, maga a portaudio, egy portaudio-debuginfo (ez nem fog kelleni), illetve a portaudio-devel csomag i686-os változata! Remek! Fel is lehet őket rakni! Az RPMS/i686 könyvtárban a

# yum install portaudio-1*.i686.rpm portaudio-devel*.i686.rpm

parancsot kiadva mindez szépen meg is történik. Jöhet (újra) az openal-soft:

$ rpmbuild -bb --target=i686 openal-soft.spec

A csomag(ok) ezek után már elkészül(nek), van négy RPM végeredmény gyanánt. Ezek az openal-soft, openal-soft-debuginfo, openal-soft-devel, openal-soft-qt. (Ennek az utolsónak kellett a qt-devel.i686, ami még az elején felkerült.) A két „lényegest” fel is kell rakni:

# yum install openal-soft-1*.i686.rpm openal-soft-devel*.i686.rpm

A két csomag felkerül egy „érdekes” megjegyzés kíséretében:

A csomagot el kellett volna távolítani, de mégsem? :-D Na mindegy, jöhet az FS-UAE csomagolási próbája, elvégre ezért volt az összes előzmény...

Először is jó lenne „kézzel” fordítani egyet próbából, hogy kiderüljön, mit hagytam ki. :) A letöltött forráscsomagot kitömörítve, majd a célkönyvtárba belépve jöhet a próba! A „kézi” fordításhoz kell a segítség a környezeti változók formájában, majd jöhet a make:

$ export CC="gcc -m32"
$ export CXX="g++ -m32"
$ export CFLAGS="-march=i686"
$ export CXXFLAGS="-march=i686"
$ make

(A környezeti változós „beállítást” valahol az interneten találtam, de – érdekes módon – fogalmam sincs, hogy hol. Pedig az ilyen linkeket el szoktam rakni mindig...)

Szinte már „természetes”, hogy hiányzik valami. :) Ezek most ketten vannak:

mesa-libGLU-devel.i686
mesa-libGL-devel.i686

Szerencsére mindkettőből van alapból csomag, szóval no para. Ezek felrakása után már lefordul a cucc szépen! Mégis lesz valami a történetből? De ha már lúd, legyen kövér: készüljön belőle csomag! A letöltött forráscsomagban van egy fs-uae.spec fájl, ezt „kiműtve” oda kell másolni a ~/RPMsanbox/SPECS könyvtárba, magát az összetömörített forrást meg a ~/RPMsandbox/SOURCES alá. Ezután jöhet a csomaggenerálás(i próba):

$ rpmbuild -bb --target=i686 fs-uae.spec

Persze ennyivel nem lehet megúszni, a „rásegítés” itt is kell:

$ export CC="gcc -m32"
$ export CXX="g++ -m32"
$ export CFLAGS="-march=i686"
$ export CXXFLAGS="-march=i686"
$ rpmbuild -bb --target=i686 fs-uae.spec

És igen, sikerül a csomaggenerálás! :) Ez a mai nap (sokadik) jó híre! :) Fel is lehet rakni:

# yum install fs-uae-2*.i686.rpm

Sőt megy is! Na de mire is volt ez a nagy küzdés? Itt az x86_64-es verzió „sebességteszt” képernyőkép, amit mutattam már:

A most kiküzdött, i686-os verzió ezzel szemben a következőt tudja:

Azt hiszem szemmel látható a különbség, röpke 5×-ös sebesség a most forgatott verzió javára, hála a JIT-es 68K emulációnak. Vajon megérte? :-D

Menet közben azért egy kicsit „csaltam”: a csomagok fordítását / generálását egy virtuális gépbe feltelepített CentOS7 alatt végigpróbáltam, mert azért minden lépésre nem emlékszik az ember. Meg sikerült egy régóta „megvizsgálandó” dolgot is megismerni, ezt azért használtam is bőszen. A fordítási próbák alatt néha sikerült olyan csomagot és függőségeit is felrakni, amik végül is nem kellettek. Emiatt jó az, ha valahogy „vissza lehet vonni” az utolsó műveletet. A yum fel van erre készítve, erre szolgál a history. A yum history list paranccsal kilistázhatók az utoljára végrehajtódott „tranzakciók”, a yum history undo ID paranccsal az ID kódú „esemény” visszavonható. (Az ID a kilistázott táblázatban a sor elején szereplő szám.) Ez a kiválasztott yum parancs minden eseményét visszavonja, tehát ha egy csomagot akart a júzer felrakni, de felkerült vele 100 másik függőségként, akkor az „undo” mind a 101 csomagot eltávolítja. A részletes yum history dokumentációt érdemes a témában megvizsgálni.

A WINE forgatása legközelebbre marad, „túl sok” feladatnak tűnik. De legalább van merre elindulni...

Update: közben eltellett egy kis idő, egy darabig nem volt szükségem az itt forgatott stuffra. De amikor használni akartam, elindulás helyett egy szép kis segfault fogadott. Szerencsére csak semmi pánik, Fedora alatt továbbra is üzemképes a ware, ettől függetlenül jó lenne kideríteni, hogy mitől „romlott el” CentOS alatt. Valamilyen frissítés lehet az okozója, csak mi? A „csalás” alatt használt virtuális gép még megvan, ott kipróbálva szépen működött a program. Csináltam rajta egy yum update-et, a frissülés után ugyanúgy működik. Hm... Próbából a 32 bites csomagokat (maga az emulátor + az openal-soft) leszedtem, helyettük vissza a 64 bites. Na, az is borul. :( Még mi változott a működés → nem működés között? Csak egy „apróság”: pár héttel ezelőtt mégis felraktam a zárt drivert a videokártyához egy bizonyos – itt most nem részletezett – okból kifolyólag. A kártyám egy nvidia 9600GT, az aktuális gyári driver meg – mint kiderült – már nem támogatja, kénytelen voltam a legacy ágat használni, itt éppen a 340.76 számú verziót. Ami miatt felraktam, azt a gondomat nem oldotta meg, :) de ezt leszámítva látszólag hibátlanul üzemelt. Visszavarázsoltam a nouveau-t, azzal az FS-UAE kiválóan működik. :-D

A móka viszont most jön: visszarakható a 32 bites emulátor, de az openal-soft 32 bites csomagját nem akarta a yum felrakni. Jött egy kis elemezgetés, hogy tulajdonképpen mi is a libbel a gond. Az elkészült csomagban „sajnos” nem csak maga a rutinkönyvtár van, hanem tartalmaz némi architektúra-független sallangot, illetve két parancsot is. A libekkel alapból nincs baj, mert az i686 és az x86_64 verziónak külön könyvtára van, de a többi cucc az „összeveszik” a 64 bites csomagban levőkkel. Készült egy teljesen lecsupaszított .rpm, amiben csak maga a rutinkönyvtár van, de a yum mindenáron a 64 bites csomag cseréjének tekintette az elkészült 32 bites verziót, nem akarta „mellérakni”. Vajon hogyan kell ilyen „multiarch” csomagpárt készíteni? Erre egyelőre nincs válasz, cserébe csináltam egy kis dirty hack gyanús megoldást: 32 bites csomag, de más néven. Nem szép, de legalább csúnya. Az az előnye megvan, hogy a „normál” openal-soft csomag frissülhet nyugodtan. A 32 bites az openal-soft32 névre lett átkeresztelve, de ebben csak a rutinkönyvtár van, a többi cucc jöhet a 64 bites csomagból. :) Ezután már nincs gond az FS-UAE-vel sem, abból is felmegy a 32 bites verzió, úgyhogy egyelőre így marad. (Persze a 340.76-os legacy nv sofőrrel továbbra se megy nálam.) A letölthető pakkban már ez a verzió van, ennek így nem kellene összeveszni semmivel.

A WINE 32 bites verziója továbbra is hátra van, viszont találtam egy fórumtopikot, ami pontosan erről a témáról szól. Mivel nem csak nekem probléma ez, arra azért volt esély, hogy valaki előbb-utóbb megcsinálja. :) Egyelőre még nem ugrottam neki, de a link majd jól fog jönni.

Linkek:

• Az FS-UAE oldala
• WINE 32 bit fordítás, kiváló kezdőlökés
• WINE 32 bit továbbra is
• Az elkészült csomagok, jól jöhet...

balagesz

---

2015.04.12.
2015.08.04. Gyári nv sofőr probléma, új [code]openal-soft[/url] csomag, WINE32
2019.12.16. D8.