„A GCC olyan mint a hagyma...” Nem lehetne inkább... ...torta? Azt mindenki szereti! (Shrek©®™ után szabadon.)

 ( balagesz | 2011. január 15., szombat - 0:08 )

A gcc fordítása az jó móka, pláne ha cross-platform fordítót akarok „építeni”... :) Legalábbis azt hittem. (A címben szereplő hasonlat az egyik HUP fórumozótól származik, van egy olyan érzésem, hogy telitalálat..!)

Kellene C-t tanulnom. Mert sajnos eddig még nem sikerült. De ez egy másik sztori. A legnagyobb probléma a tanulással az, hogy olyan feladatot találjak, ami van annyira egyszerű, hogy meg merjem próbálni egy – egyelőre – ismeretlen nyelven megírni, viszont értelme is van meg érdekel is. Hát, azt hiszem most eljött ez a pillanat, de egy ideje már készülök a feladatra. A „terep” egy mikrokontroller; pc-s programozás nem érdekel. Ez meg a másik probléma a tanulással, viszont ez most részletkérdés.

A „target” egy Atmega88-as uC lesz, a fordítást meg maga a gcc fogja végrehajtani. Összeraktam prototípus-nyákon a kapcsolást (van benne az ATmega88-on kívül pár relé a hozzá tartozó meghajtóval, meg egy MAX232 ami egy soros-porti illesztő, ill. egy nyomógomb, meg egy LED), megírtam az (mondjuk úgy) első C-s programom, felprogramoztam a kontrollerbe. Ha bekapcsolom a kütyüt, világít a LED. Ha lenyomom a gombot, elalszik. Ha elengedem, újra bekapcsol. (SZERINTEM kb. ez a uC-es „hello world!” mintaprogram. Mindenki VILLOGTATNI akarja a LED-et, de az már a V2.0-ás változat, ugyanis ahhoz várakozni kell... :) ) Most itt tartok. Kb. 5 perce néha nyomok egyet a gombon, a cucc még mindig azt csinálja amit kell neki, én meg csak nem bírom rávenni magam hogy folytassam, inkább ezt a bejegyzést irkálom... De ahhoz hogy idáig el tudjak jutni, ezt megelőzte 2-3 hónap küzdés. (Azért nem folyamatos szerencsére, csak amikor kedv/idő volt rá, akkor foglalkoztam vele.) A leírás ennek a küzdésnek a végeredménye, a jelenlegi (2011.01.14.) legfrissebb verziókkal. A szívások (mert volt bőven) jó részét nem írom le, így is jó hosszú lesz...

Jelenleg két disztribúciót használok: egy Fedora14-et ill. egy CentOS5.5-öt. A (mindig aktuális verziójú) Fedora a „homokozó” disztribúció: a csomagok szinte vadonatújak, van belőlük rengeteg, minden friss, bármi kipróbálható, viszont emiatt izgalmas is. A CentOS ellenben egyszerűen csak működik. :) Az ember ahogy öregszik, úgy tudja egyre inkább értékelni ezt a feature-t. Tehát a feladat: kellene nekem egy avr-toolchain. Fedora alatt ez nem gond:

# yum install avr-* (Vagy valami ilyesmi.)

Ez felpakolja a binutils, gcc, gcc-c++, gdb, libc csomagok avr-es verzióját, mindből az aktuális friss cuccot. Ez szép meg jó, de az F14-et csak próbálgatás miatt „használom”, dolgozni jobban tetszik a CentOS a maga egyhangúságával (azért várom már a 6-os szériát... :) ). Úgyhogy ez nekem CentOS alá kéne, ott persze nincs a repó(k)ban... Van pár csomag, amiből a (valamelyik) Fedora változatot szedtem le és raktam föl. Így van 1.90.0-ás (bugos...) Krusader-em például. (Csak olyan csomagot raktam így föl, aminek nem volt olyan függősége, ami ne lett volna meg. Tehát a rendszer nincs „megerőszakolva”.) De ezt megpróbálva az avr-* csomagokkal a következőt kaptam:

error: Failed dependencies: 
..libc.so.6(GLIBC_2.11) is needed by avr-binutils-2.20-2.fc13.i686 
..libc.so.6(GLIBC_2.7) is needed by avr-binutils-2.20-2.fc13.i686 
..libc.so.6(GLIBC_2.8) is needed by avr-binutils-2.20-2.fc13.i686 
..rpmlib(FileDigests) <= 4.6.0-1 is needed by avr-binutils-2.20-2.fc13.i686 
..rpmlib(PayloadIsXz) <= 5.2-1 is needed by avr-binutils-2.20-2.fc13.i686 

Szóval ez az út ebben az esetben nem járható, egy glibc-t csak nem cserélek le... A neten kész csomagot keresve nem jutottam eredményre: azt hiszem nem sok olyan őrült van mint én, hogy RH alapú desktop-on akar avr-gcc-t használni. Kellemetlen... (Meg amúgy is: ismeretlen eredetű cuccot csak úgy felpakolni... Hm... Nem éppen fincsi.)

Tehát a „terv” kész: fordítok egy sajátot. Mi az nekem... :)

Gondoltam, előtte megnézem hogyan csinálják ezt a „nagyok”. Keresgélve a neten, ráakadtam két komplett shell szkriptre is, ami tulajdonképpen megcsinál mindent. A megfelelő helyről letölti a kellő forrás-csomagokat, kicsomagolja, fordítja, telepíti... Az ígéretesebbet próbáltam ki másodszor, mivel ennek a letöltéséhez regisztrált tagnak kell az oldalon lenni. Ebből következik, hogy az első nem működött valami tökéletesen. Elindítva nekiállt dolgozni, (letöltés, forgatás...), majd a megállt hibával, hogy a gdb-t nem tudja valami miatt lefordítani. (A pontos okra már nem emlékszem, természetesen valami függőségi gond.) Ciki, de egyelőre debug nélkül megvagyok, majd megnézem később hogy mi a nyűgje. Viszont a fordítás végén hiányzott két parancs (minimum...) az elérési útból: az avr-gcc és az avr-g++! Ez így akkor nem lesz jó... :)

Na, akkor regisztrálás avrfreaks.net-re, szkript letöltése, ReadMe gondos átolvasása... Megnéztem hogy „most” miből mi az aktuális legfrissebb stabil (-nak nyilvánított) verzió, a szkriptben átírtam a hivatkozásokat, ahogy kell. A szerző ezt a szkriptet Ubuntura csinálta, semmi okom feltételezni hogy ott nem működik. De CentOS-on szépen elhasal ez is... Valami szokásos függőségi nyűg. Kavartam egy kicsit a verziókkal (valahol azt olvastam, hogy sokszor bizonyos verziók csak együtt fordulnak; mondjuk ez a gcc-avr-libc viszonylatban érdekes csak...), de a végén megpróbáltam az „eredeti” változatot is (ami a szkriptben gyárilag szerepel). Csak nem fordul, ...

Ami mindkét szkriptet jellemzi: nem a most elérhető legfrissebb verziókat fordítanák, ill. nincs bennük hibakezelés, ami a nagyobbik baj. Ha valami „nem fordul” és megáll hibával, a szkript simán elkezdi a következő feladat végrehajtását, látni meg a legutolsó hibát lehet csak. Azt meg fölöslegesen nézegetem... Nem jó ez így...

Tehát akkor megpróbálom „kézzel”. De ha valami sikerül, lehet hogy másnapra elfelejtem hogyan csináltam, úgyhogy írhatok saját szkriptet (szkripteket) is, nem? „Az” legalább majd dokumentál. Meg „abba” rakhatok hiba-figyelést. Meg „az” azt fogja csinálni, amit akarok. Legalábbis ez a terv, ugyanis 1-2 soros shell szkripten kívül komolyabbat még nem írtam, ehhez sem értek...

Keresgetve a neten találtam több „kézi” fordításos leírást is:

http://www.micahcarrick.com/installing-gnu-tools-avr-gcc.html
http://www.linux.org.ru/forum/development/3143232
http://pigpigchan.blogspot.com/2009/07/avr-building-avr-toolchain-under-linux.html

Ezek nagy vonalakban ugyanazt mondják el:

  1. Töltsd le a binutils-t
  2. Tömörítsd ki
  3. Futtasd a configure-t a megfelelő paraméterekkel
  4. Futtasd a make-t
  5. Installáld föl a make install paranccsal
  6. Hajtsd végre ugyanezeket a gcc-vel
  7. Hajtsd végre ugyanezeket a gdb-vel
  8. Hajtsd végre ugyanezeket a avr-libc-vel

Na, ez nem tűnik túl bonyolultnak, viszont van egy kis bibi:

checking for the correct version of gmp.h... no 
configure: error: Building GCC requires GMP 4.2+, MPFR 2.3.1+ and MPC 0.8.0+. 
Try the --with-gmp, --with-mpfr and/or --with-mpc options to specify 
their locations.  Source code for these libraries can be found at 
their respective hosting sites as well as at 
ftp://gcc.gnu.org/pub/gcc/infrastructure/.  See also 
http://gcc.gnu.org/install/prerequisites.html for additional info.  If 
you obtained GMP, MPFR and/or MPC from a vendor distribution package, 
make sure that you have installed both the libraries and the header 
files.  They may be located in separate packages. 

Tehát ezért nem működik egyik letöltött szkript se, csak bambán végigmegy a fordítandó feladatokon, ha nem sikerül akkor csinálja a következőt. Így aztán kereshetem az avr-gcc-t... :)

Tehát a gcc-nek (ill. a binutils meg a gdb is linkelné, ha van) kell 3 lib:

GMP (4.2+)
MPFR (2.3.1+)
MPC (0.8.0+)

De vajon mi van ezekből alapban a CentOS-ban?

Package gmp-4.1.4-10.el5.i386 already installed and latest version

Ez „messze” van a 4.2+-tól. Viszont MPFR ill. MPC néven nincs csomag egyáltalán... (Az lehet hogy valamihez hozzá van dobva, ezt nem tudom, de most nem is érdekes. Ha kell új lib, szinte mindegy hogy mennyi... :) )

Megnézve a hivatkozott ftp oldalt valóban ott van a hiányzó csomagok mindegyike (még szép):

  1. gmp-4.3.2.tar.bz2
  2. mpfr-2.4.2.tar.bz2
  3. mpc-0.8.1.tar.gz

Viszont vannak ezekből újabbak is:

  1. GMP: http://gmplib.org/#DOWNLOAD
  2. MPFR: http://www.mpfr.org/mpfr-current/#download
  3. MPC: http://multiprecision.org/?prog=mpc&page=download

GMP-ből („GMP is a free library for arbitrary precision arithmetic, operating on signed integers, rational numbers, and floating point numbers.”) az 5.0.1-es, MPFR-ből („The MPFR library is a C library for multiple-precision floating-point computations with correct rounding.”) a 3.0.0-ás, MPC-ből („MPC is a C library for the arithmetic of complex numbers with arbitrarily high precision and correct rounding of the result.”) a 0.8.2-es. Ha már van belőlük frissebb, akkor legyenek ezek használva... (Hogy jó ötlet-e, az majd elválik. Persze az is kérdéses, hogy itt az AVR-es változatban ebből mi lesz használatban, eléggé „tudományos” libeknek tűnnek ezek... Fogalmam sincs, hogy ezeket a gcc saját maga használja, vagy az általa fordított cuccokban lesz/lenne szerepe. Esetleg mindkettő?...)

Tehát a terv: lesz saját csomag. Hehe... De hogy hogyan? Az RPM generálása egy külön téma lesz, ahhoz se értek, de egyelőre legyen meg a „belevaló”.

Kezdésnek csinálok egy munkakönyvtárat, ez lesz az „alapkönyvtár”, ebbe fogok dolgozni. Praktikusan a home-ban, ez most nálam a ~/5 könyvtár. :)

Utána csinálok egy könyvtárat, EBBE mehet a fordítás végeredménye:

$ mkdir CrossTools

Ill. lesz egy külön könyvtár a fordított libeknek is:

$ mkdir CTlibs

Majd gyorsan „meg is jegyzem”, ugyanis ez lesz a cél könyvtár, ahova az „install” fog menni, ill. az elérési úthoz is hozzáadom ami kell, meg a libek elérési útja is beállításra kerül:

$ export PREFIX=$PWD/CrossTools
$ export LIBPREF=$PWD/CTlibs
$ export PATH=$PATH:$PREFIX/bin
$ export LD_LIBRARY_PATH=$LIBPREF/lib

Ezek lesznek az „alap beállítások”, ami ezután jön, az csak akkor fog normálisan végigfutni, ha ezek be vannak állítva! (Tehát ha egy másik terminál-ablakot nyitsz, abba újra be kell állítani ezeket, csak akkor lehet folytatni. Mivel ezeket a rendszer nem jegyzi meg örökre... A lényeg a PATH ill. az LD_LIBRARY_PATH környezeti változó, a többi csak segítség.)

Készül egy downloads könyvtár, ebbe töltök le MINDENt, ami most kelleni fog:

$ mkdir downloads
$ cd downloads

Majd ebbe a könyvtárba letöltöm, ami kell:

  1. GMP: ftp://ftp.gnu.org/gnu/gmp/gmp-5.0.1.tar.bz2
  2. MPFR: http://www.mpfr.org/mpfr-current/mpfr-3.0.0.tar.bz2
  3. MPC: http://multiprecision.org/mpc/download/mpc-0.8.2.tar.gz
  4. BinUtils: ftp://ftp.gnu.org/gnu/binutils/binutils-2.21.tar.bz2
  5. GCC-Core: ftp://ftp.gnu.org/gnu/gcc/gcc-4.5.2/gcc-core-4.5.2.tar.bz2
  6. GCC-G++: ftp://ftp.gnu.org/gnu/gcc/gcc-4.5.2/gcc-g++-4.5.2.tar.bz2
  7. GDB: ftp://ftp.gnu.org/gnu/gdb/gdb-7.2.tar.bz2
  8. AVR-LibC: http://download.savannah.gnu.org/releases/avr-libc/avr-libc-1.7.0.tar.bz2

Kezdődhet a móka! Mivel a rendszerben a libeket nem akarnám felülcsapni, a jó(-nak tűnő) megoldás az lehet, ha statikusan lesznek linkelve. (Ismerem a problémát, ami miatt ez erősen ellenjavallt, de most ez nem érdekel, már bocsánat!) A statikus linkelést úgy lehet elérni, hogy a libeket fordítom úgy, hogy csak statikusan linkelhető végeredmény forduljon, ezért lényeges ez az infó itt... :) A libek fordítási sorrendje nem mindegy, ugyanis egymásra (is) épülnek.

Először jön a GMP (Kicsomagolás, konfigurálás, fordítás, installálás):

$ tar -xjf gmp-5.0.1.tar.bz2
$ cd  gmp-5.0.1
$ mkdir build
$ cd build
$ ../configure --prefix=$LIBPREF
$ make LDFLAGS=-all-static
$ make install

Lefutott, remek! (Itt a make paramétere mondja meg, hogy csak statikusan linkelhető legyen a végeredmény.) Viszont azt írja a kimenet, hogy a make check futtatása ezután erősen javallott. Akkor legyen:

$ make check
$ cd ../..

Másodszor az MPFR (Ez is kicsomagol, konfigurál, fordít, installál), de ennek majd meg kell adni, hogy a GMP-t (ami az előbb fordult) hol találja:

$ tar -xjf mpfr-3.0.0.tar.bz2
$ cd mpfr-3.0.0
$ mkdir build
$ cd build
$ ../configure --prefix=$LIBPREF --with-gmp=$LIBPREF
$ make LDFLAGS=-all-static
$ make install
$ cd ../..

Harmadiknak jön az MPC (eXtract, Configure, Make, Install), ennek az előző 2 lib elérése kell:

$ tar -xzf mpc-0.8.2.tar.gz
$ cd mpc-0.8.2 
$ mkdir build 
$ cd build 
$ ../configure --prefix=$LIBPREF --with-mpfr=$LIBPREF --with-gmp=$LIBPREF
$ make LDFLAGS=-all-static
$ make install
$ cd ../..

Miután ez megvan, a $LIBPREF könyvtár lib ill. include alkönyvtáraiban már gyűlik a szajré szépen, de most ez volt a cél.

Jöhet végre az ~érdemi munka! Binutils (X, C, M, I), ennek már meg kell adni a 3 lib helyét (A binutils amúgy lefordul ezek nélkül is érdekes módon, de ha már van hozzá paraméter, akkor megadom!):

$ tar -xjf binutils-2.21.tar.bz2
$ cd binutils-2.21 
$ mkdir build 
$ cd build
$ ../configure --target=avr --prefix=$PREFIX --program-prefix=avr- --disable-nls --with-mpc=$LIBPREF --with-mpfr=$LIBPREF --with-gmp=$LIBPREF
$ make
$ make install
$ cd ../..

Miután végzett, a $PREFIX könyvtárban megjelennek az első biztató jelek („avr-” kezdetű cuccok tömkelege a /bin-ben... :) ), de ez csak a kezdet! Jöhet a gcc (X, C, M, I), szintén a 3 lib lelőhelyével:

$ tar -xjf gcc-core-4.5.2.tar.bz2 
$ tar -xjf gcc-g++-4.5.2.tar.bz2
$ cd gcc-4.5.2
$ mkdir build
$ cd build
$ ../configure --target=avr --prefix=$PREFIX --program-prefix=avr- --disable-libssp --disable-nls --enable-languages=c,c++ --with-dwarf2 --with-mpc=$LIBPREF --with-mpfr=$LIBPREF --with-gmp=$LIBPREF
$ make
$ make install
$ cd ../..

Na! Mik vannak a $PREFIX/bin konyvtárban? Például avr-gcc! Eddig siker van kéremszépen...

Tehát van AVR-es gcc-m. Jöhet a gdb, hátha jó lesz még az is! (X, C, M, I):

$ tar -xjf gdb-7.2.tar.bz2 
$ cd gdb-7.2 
$ mkdir build 
$ cd build
$ ../configure --target=avr --prefix=$PREFIX --program-prefix=avr- --disable-nls --with-mpc=$LIBPREF --with-mpfr=$LIBPREF --with-gmp=$LIBPREF
$ make
$ make install
$ cd ../..

És igen, van avr-gdb is... Csak alakul ez!

Akkor nézzük meg, mink is van! Nyitok egy új terminálablakot, majd:

$ avr-gcc --version

Hát ja, nincs alapból az elérési útban. Hozzáadom:

$ export PATH=$PATH:/home/work/5/CrossTools/bin
$ avr-gcc --version

Ez már jobban néz ki! A külön terminálablak azért kell, hogy látszódjon az, kell-e neki KÜLÖN a leforgatott libek közül valami. Hát, siker, ugyanis – úgy tűnik – nem kell...

Jöhet az avr-libc forgatása, ez a feladat a most forgatott avr-gcc-re hárul... Ezzel lehet tesztelni is jól, hogy minden megfelelően működik-e!

Ennek is készül egy „cél” könyvtár a downloads, CrossTools, CTlibs könyvtárak mellé:

$ mkdir AVRlibC
$ export ALCPREF=$PWD/AVRlibC
$ cd downloads
$ tar -xjf avr-libc-1.7.0.tar.bz2
$ cd avr-libc-1.7.0

Itt a configure a következőket mondja:

$ ./configure
configure: WARNING: AVR-LIBC must be built using an avr cross-compiler. 
configure: WARNING: Try configuring with: 
configure: WARNING: "./configure --build=`./config.guess` --host=avr" 
configure: error: aborting configure 

Tehát futtassam így:

$ ./configure --build=`./config.guess` --host=avr --prefix=$ALCPREF

Ez szépen lefut. Jöhet a make:

make

Hát, ennek a végeredménye annyira már nem szép:

Hogy semmi se lehet egyszerű...

make[5]: *** [gcrt1.o] Error 1 
make[5]: Leaving directory `/home/work/5/downloads/avr-libc-1.7.0/avr/lib/avr25/attiny2313a' 
make[4]: *** [all-recursive] Error 1 
make[4]: Leaving directory `/home/work/5/downloads/avr-libc-1.7.0/avr/lib/avr25' 
make[3]: *** [all-recursive] Error 1 
make[3]: Leaving directory `/home/work/5/downloads/avr-libc-1.7.0/avr/lib' 
make[2]: *** [all-recursive] Error 1 
make[2]: Leaving directory `/home/work/5/downloads/avr-libc-1.7.0/avr' 
make[1]: *** [all-recursive] Error 1 
make[1]: Leaving directory `/home/work/5/downloads/avr-libc-1.7.0' 
make: *** [all] Error 2 

De ebből semmilyen lényegi információ nem derül ki. Egy kicsit visszább nézve a kimenetet, látszik valami érdekes:

Making all in attiny2313a 
make[5]: Entering directory `/home/work/5/downloads/avr-libc-1.7.0/avr/lib/avr25/attiny2313a' 
avr-gcc -DHAVE_CONFIG_H -I. -I../../../..  -I../../../../common -I../../../../include -I../../../../include  -I../../../../common -I../../../../include -I../../../../include -x assembler-with-cpp -Wa,-gstabs -mmcu=attiny2313a    -MT gcrt1.o -MD -MP -MF .deps/gcrt1.Tpo -c -o gcrt1.o ../../../../crt1/gcrt1.S 
unknown MCU 'attiny2313a' specified 
Known MCU names: 
   avr2 
..........
   attiny28 
In file included from ../../../../common/macros.inc:39:0, 
                 from ../../../../crt1/gcrt1.S:38: 
../../../../include/avr/io.h:422:6: warning: #warning "device type not defined" 
../../../../crt1/gcrt1.S: Assembler messages: 
../../../../crt1/gcrt1.S:53: Error: non-constant expression in ".if" statement 
..........
../../../../crt1/gcrt1.S:179: Error: non-constant expression in ".if" statement 

Majd ezután jön a vége, ami fenn látszik. Mi a búbánat lehet ez? Leginkább a kimenet végére koncentrálva próbáltam értelmes kifejezésekkel találatokat kicsikarni a keresőből, eredménytelenül... (Ugyanis nem ott van a lényeg. De erre csak később jöttem rá.) Vajon valahogy rosszul fordítottam a gcc-t? Rossz paraméterekkel? Végigpróbáltam egy csomó változatot, de a végeredmény csak nem lett jó... Vagy hibás esetleg az avr-libc? Fedora alatt van belőle csomag, ráadásul ugyanebből a verzióból. Azt fel lehet rakni minden gond nélkül, „működik” is, de ne már hogy az általam forgatott gcc nem bírja lefordítani... Gyorsan „átbootoltam” F14 alá, avr-libc kézi forgatása... És ott simán lefordul. (Illetve: MA MÁR nem fordul le... :) Nem pont „ez” a hiba, de hasonló... Amikor ezzel küzdöttem, akkor lefordult! Hehe... Most vagy valami olyan változás történt, amit nem értek, vagy csak álmodtam az egészet. Ciki...) Na, akkor pláne mi a búbánat ez? Tuti valami forgatási nyűg lesz! Egy darabig nem foglalkoztam az esettel, de persze csak nem hagyott nyugodni... Ki kellene deríteni, hogy milyen paraméterekkel fordították a Fedora-s csomagot. Letöltöttem a forrás-rpm-et, (ez mondjuk a fejlesztői ágban lévő verzió), majd szétkaptam:

$ rpm2cpio avr-gcc-4.5.1-3.fc15.src.rpm | cpio -id

Gondoltam, hogy kinézem a paramétereket a SPEC fájlból. De a szétkapott csomagban találtam egy „érdekes” fájlt, aminek a neve:

avr-gcc-4.5.0-new_devices.patch

Amikor ezt megláttam, konkrétan lefejeltem a billentyűzetet...

Arról van szó, hogy a legfrissebb avr-gcc nem elég friss a legújabb avr-libc lefordításához. Én ennek annyira örülök... :) Viszont az egésznek konkrétan SEMMI ÉRTELME. Belenézve a .patch-be, az látszik, hogy egy csomó „A” végződésű uC került bele. Aminél lehalt a fordítás, az is ilyen: attiny2313a. DE! Ezek az eszközök a „nem A” végűektől csak gyártástechnológiában különböznek, jobbak az elektromos paramétereik. Programozás (meg még programletöltés, amiről most szó sincs) szempontjából NINCS különbség a két verzió között. Tehát ha én „attiny2313A”-ra akarok kódolni, akkor beállítok „attiny2313”-at, aztán kész. Ráadásul az avr-libc configure ellenőrzi az avr-gcc-t, hogy milyen eszközöket támogat (legalábbis megy egy lista a vizsgálatról...), tehát tudhatná, hogy az „A”-s végűek nem mennek. Akkor miért akarja forgatni azokat is? Nem értem én ezt...

Van amúgy egy másik .patch is:

avr-gcc-4.5.1-register-fix.patch

Megnézve a 4.5.2-es gcc forrását, ez a fix sincs még benne, úgyhogy ezt is bele lehet tolni... (Ezt legalább értem hogy mi: szubrutinhívás előtt ment egy regisztert, majd utána visszaállítja. AVR ASM rulez... Hogy mikor milyen hibát javít ez (ha egyáltalán javít) az nem derül ennyiből ki számomra.) Az avr-gcc-4.5.0-new_devices.patch az így rendben is van, de az avr-gcc-4.5.1-register-fix.patch fájlt meg kell peccselni, hogy jó legyen:

--- gcc-4.5.1.orig/gcc/config/avr/libgcc.S
+++ gcc-4.5.1.orig/gcc/config/avr/libgcc.S

Ez az első két sor, ebben kell az elérési utat átírni:

--- gcc/config/avr/libgcc.S
+++ gcc/config/avr/libgcc.S

A két .patch fájlt ezután be lehet másolni a downloads könyvtárba, jöhet újra a gcc fordítása jól, de VISSZA a „régi” terminálablakba:

$ echo $LD_LIBRARY_PATH
$ echo $PATH

A kimenetek alapján még mindig be van állítva a beállítandó, úgyhogy jöhet a forgatás újra:

$ rm -rf gcc-4.5.2
$ tar -xjf gcc-core-4.5.2.tar.bz2 
$ tar -xjf gcc-g++-4.5.2.tar.bz2
$ cd gcc-4.5.2
$ cp ../avr-gcc-4.5.0-new_devices.patch ./
$ patch -p0 < avr-gcc-4.5.0-new_devices.patch
$ cp ../avr-gcc-4.5.1-register-fix.patch ./
$ patch -p0 < avr-gcc-4.5.1-register-fix.patch
$ mkdir build
$ cd build
$ ../configure --target=avr --prefix=$PREFIX --program-prefix=avr- --disable-libssp --disable-nls --enable-languages=c,c++ --with-dwarf2 --with-mpc=$LIBPREF --with-mpfr=$LIBPREF --with-gmp=$LIBPREF
$ make
$ make install
$ cd ../..

Ez is megvolt, lássuk hogy mit sikerült alkotni! Vissza az avr-libc-s terminálablakba, majd új fordítás...

$ make

Hát... Ugyanúgy elhasal, de most az atmega6490a a nem támogatott eszköz. (Ez a hiba ugyanaz, ami a Fedora-s fordítónál is előjön... De ez „régen” ott is működött, ill. az általam CentOS-ra fordított verzióval is ment! Ez annyira így van, hogy megvan az a ~3 hónappal ezelőtt forgatott csomag, amit ha felrakok most, azzal simán lefordul... :) Mondjuk az a gcc 4.5.1-es verziója, érdemes lesz körülnézni, hogy mi változott!)

Az avr-gcc-4.5.0-new_devices.patch fájlba belenézve azért látszik pár érdekesség. Ennek a segítségével 2 fájl peccselődik, a gcc/config/avr/avr-devices.c ill. a gcc/config/avr/t-avr. A másodikban szerepel hozzáadásként az atmega6490a ill. az atmega6490p, de az elsőből hiányoznak! Nahát... Kell csinálnom egy saját patch-et? Szép... Kezd ez egyre cifrább lenni... A patch-elt avr-devices.c-be beleírtam a két hiányzó sort, újraforgattam. Az avr-libc forgatása tovább ment, más helyen, később, máshogy, de elhasalt így is...Remek. Vajon a „régen működő” változat hogy néz ki?

Lehúztam a gcc 4.5.1-es forrását, kicsomagoltam, belenéztem, hát... Abban sincs benne az atmega6490a! Akkor meg mi a túró van?! A 2 patch beletol, fordít, avr-libc fordítás ugyanúgy nem működik...

Mi volt még más ~3 hónapja? A binutils. Abból a 2.20.1-es van a ~3 hónapos csomagomban, lehúzva az is, kicsomagol, fordít:

$ tar -xjf binutils-2.20.1.tar.bz2
$ cd binutils-2.20.1
$ mkdir build
$ cd build
$ ../configure --target=avr --prefix=$PREFIX --program-prefix=avr- --disable-nls --with-mpc=$LIBPREF --with-mpfr=$LIBPREF --with-gmp=$LIBPREF
$ make
$ make install
$ cd ../..

Jöhet az avr-libc fordítása a saját ablakában újra:

$ make

Újra „lehal” az atmega6490a-nél... Ez azért érdekes. De legyen egy „friss” fordítási próba:

cd ..
$ rm -rf avr-libc-1.7.0
$ tar -xjf avr-libc-1.7.0.tar.bz2
$ cd avr-libc-1.7.0
$ ./configure --build=`./config.guess` --host=avr --prefix=$ALCPREF
$ make
$ make install

Ezután az avr-libc érdekes módon lefordul hibátlanul... Remek. Jöhet vissza a 4.5.2-es gcc. Azzal is fordul... Tehát a „bűnös” a 2.21-es binutils! Bár azért nem túl meggyőző, de azt visszarakva a régebbire, tulajdonképpen működik... Ez az új eszközös patch megérne egy alaposabb átvizsgálást, viszont ehhez (Még! :) ) nem értek. Úgyhogy egyelőre marad a Fedora-s „gyári” változat.

Jó lenne viszont, ha lenne ebből a forgatásból valami csomagféle... *.RPM-et se csináltam még; egyelőre nem találtam róla olyan dokumentációt, amit meg is értettem volna. (Valaki esetleg?) Jelenleg az egyetlen lehetőségem az alien, az tud *.tar.gz-ből RPM-et kreálni. Függőségek nincsenek (khm...), azzal úgyse kell foglalkozni. Tehát akkor vissza az „alapkönyvtárba”, a downloads könyvtár mellé készítek egy „RPM” könyvtárat, ahova összemásolom a struktúrát:

$ mkdir -p RPM/usr

Utána jöhetnek a belevalók:

$ cp -R $PREFIX/avr RPM/usr/avr
$ cp -R $PREFIX/bin RPM/usr/bin
$ cp -R $PREFIX/lib RPM/usr/lib
$ cp -R $PREFIX/libexec RPM/usr/libexec
$ mkdir -p RPM/usr/share
$ cp -R $PREFIX/share/man RPM/usr/share/man

Ezek lesznek a csomagban. Viszont ez így méretre mennyi is? Hát... 180MB! Ejha! Brutális... A binárisok tele vannak mindenféle fölösleges dologgal (debuginfo, ...), amit a strip szépen ki tud gyomlálni:

$ strip RPM/usr/bin/*
$ strip RPM/usr/avr/bin/*
$ strip RPM/usr/libexec/gcc/avr/4.5.2/*
$ strip RPM/usr/libexec/gcc/avr/4.5.2/install-tools/*

Na így mennyi lett? 51MB! Ez azért egyből szebb... Ez se kicsi (köszönhető a statikus linkelésnek?) de azért már kezelhető... Tehát akkor jöhet az RPM csomag legenerálása:

$ cd RPM
$ tar -cvf avr-toolchain-20110114.i386.tar *
$ gzip -9 avr-toolchain-20110114.i386.tar

Összeállt a „tar.gz csomag”, jöhet az alien! Ez egy kicsit „trükkös”, ugyanis ebből sincs CentOS-os csomag, de Fedora alatt se találni... Viszont mókás a cucc (egy „szép” perl szkript amúgy), mert a nem telepített változat is használható, az a lényeg hogy a kicsomagolt alien könyvtárba kell bemásolni azt, amit át kell alakítani „valamivé”. Majd jöhet az átalakítás:

$ ./alien.pl -r avr-toolchain-20110114.i386.tar.gz

Egy kicsit hisztizik:

Warning: alien is not running as root! 
Warning: Ownerships of files in the generated packages will probably be wrong. 

Mivel NEM root-ként fut, lehet hogy a generált csomagban a fájlok tulajdonosa nem lesz jó, de ezt én most figyelmen kívül hagyom; a csomag feltelepítése után root lesz a tulajdonosa mindnek.

avr-toolchain-20110114.-2.noarch.rpm generated

De azért szépen elkészül a csomag. Látszik viszont egy „szépséghiba”: noarch lett az architektúra, pedig i386 kellett volna... Az alien-nek nem találtam olyan beállítását, amivel ezt lehetne „szabályozni”, ha automatikusan ezt találta ki, akkor mellé... De ez most nem érdekel, az a lényeg, hogy telepíthető/eltávolítható, amikor akarom! Végül is: ez is volt a cél!

Ugyanezt az avr-libc-vel is el kell játszani, kiindulási pontnak újra az „alapkönyvtár”:

$ mkdir -p ALCRPM/usr
$ cp -R AVRlibC/* ALCRPM/usr

Összemásolva, jöhet a csomagolás:

$ cd ALCRPM
$ tar -cvf avr-libc-1.7.0.tar *
$ gzip -9 avr-libc-1.7.0.tar

Összeállt az archív, jöhet az idegen:

$ ./alien.pl -r avr-libc-1.7.0.tar.gz

A végeredmény:

avr-libc-1.7.0-2.noarch.rpm generated

Ez már valóban noarch, mivel ami architektúra-függő, az AVR-es kód, de azt úgyse a fejlesztői gépen futtatják. Tehát bárhova fel lehet rakni! Akkor: két csomag felrak:

# rpm -i avr-toolchain-20110114.-2.noarch.rpm
# rpm -i avr-libc-1.7.0-2.noarch.rpm

Fordul a „Hello World!” mintaprogim?

Simán! Végre lett egy saját toolchain-em... :)

Egy kis összegzés a végére:

A CentOS-ban a következő cuccok vannak a fordításhoz:

  1. binutils: 2.17.50.0.6-14.el5 20061020
  2. gcc: 4.1.2 20080704 (Red Hat 4.1.2-48)
  3. make: 3.81

Ami fordult és (úgy látom) működik is:

  1. gmp-5.0.1
  2. mpfr-3.0.0
  3. mpc-0.8.2
  4. binutils-2.20.1
  5. gcc-4.5.2
  6. gdb-7.2
  7. avr-libc-1.7.0

A gcc-t lehetett volna amúgy máshogy is fordítani. Az egyik leírás említi is, hogy ha bizonyos verziónál (talán 4.4.0?) újabbat akarnák fordítani, akkor kelleni fog neki a gmp meg az mpfr (ill. mint kiderült, az mpc is), ezeket másoljam be a gcc forrás gyökérbe verziószám nélküli könyvtárnévvel. Majd futtassam így a configure-t. Ez akkor – valamiért – nekem nem működött, de most kipróbálva simán... :) Ebben az esetben nem kell az LD_LIBRARY_PATH környezeti változót beállítani (Lehet hogy nem is szabad!), és a végeredmény is mintha statikus linkeléssel készülne, mert a lib könyvtárban nem lesz belőle semmi. A binutils meg a gdb lefordul enélkül is. (Legalábbis itt, CentOS-on.) Feleslegesen túráztam? Na mindegy, sokat tanultam belőle! Köszönhető ez leginkább az egyik haveromnak ill. a barátnőjének: ugyanis rengeteget segítettek, ezúton is KÖSZÖNÖM!

Szóval működik, viszont ez a peccselős dolog annyira nem tetszik. (Hajlok afelé, hogy a 2 eszköz hozzáadása utáni hiba az valami avr-libc hiba lesz, csak a „régi” binutils hibája miatt fordul le, tehát jónak látszik, de hibás. Persze ez csak egy gondolatmenet, a tévedés jogát fenntartom! :) ) Jó lesz ez így C-t tanulni, azt a tokot (atmega6490a) nem használom, de remélem hogy nem fog a „nagy tanulásban” cserbenhagyni a toolchain... A gdb-t még nem próbáltam, az is egy külön tanulást meg fog érdemelni. (Egyelőre több a kérdés vele kapcsolatban mint válasz, de majd az is alakul.)

Lassan jöhet a többi – engem érdeklő (68k, ARM, ...) – architektúra fordítása is... :)

balagesz

---

2011.01.14.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Szvsz ennyi idő/energia befektetésével már betéve ismernéd a C++ -t és a komplett STL-t.

Ú szép menet volt. nem olvastam sikerült végül is?

Nekem cent5-ön egy friss transmissionba is beletört a bicskám,
várjuk már azt a 6-ot. :S

>>: sys-admin.hu :<<

Tulajdonkeppen siker a "project", bar van egy ket kerdeses resz. De az nem magaval a forditassal, hanem a forditott cuccal van... A 6-ost mar en is varom, kivancsi leszek mennyire lesz "regi". :)

nem ismerem c6 mostani allapotat, de nemlehet azt megcsinalni, hogy chrootba feltolsz egy 6-ost, es abban dolgozol? igy a sajat rendszeredet nemkell szetturni (az X-et, firefox-ot, stb meg tovabbra is a mostani rendszered adja), a chroot konyvtarat meg barmikor letorolheted, es kezdheted elorol.

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Ehhez nem ertek, de miben is lenne ez nekem jo? :) Pont azokbol lenne ertelme ujabbakat hasznalni, amiket irsz, persze IMHO. Amugy a leirasbol "helyhiany" miatt kimaradt: az elejen pont azt terveztem, hogy ha nem sikerul a moka, akkor megprobalok egy chroot-olt kornyezetet (csak meg az 5-ost), amiben a libeket felulirhatom nyugodtan. De aztan nem lett ra szukseg.