Fórumok
Keresztfordító kellene - az RPI fájdalmasan lassú.
Debian Wheezy 64 bit felállás - semmi különös.
Ezen a vonalon indultam el:
http://jeremy-nicola.info/portfolio-item/cross-compilation-distributed-…
Szépen letöltöttem:
$git clone https://github.com/raspberrypi/tools.git --depth=1
Próba a szokásos "Hello world", hiba:
"version 'GLIBC_2.14' not found (required by ... arm-linux-gnueabihf-gcc-4.8.3)
Végül is érthető, de most ezzel mit csináljak? Lövésem nincs?
Túrom a google -t egyenlőre nem találok semmi használhatót azonkívül, hogy használjak testing -et.
SZERKESZTVE: A "tools" doksija szerint a Debian 6.0.2 verzióját támogatja. Az milyen verzió? - én a 6.0.10 -nél leragadtam :(
Hozzászólások
Mondhatnám megoldva?
Kb. egy évvel ezelőtt, már eljutottam a "Hello world!" lefordításáig, ezzel a howto -val:
http://www.bootc.net/archives/2012/05/26/how-to-build-a-cross-compiler-…
Jobb híján, feltelepítettem egy Squeeze i386 és azon csontnélkül működik!
Talán annyit kell hogy a szokásos fordításokhoz szükséges infrastruktúrán kívül, fel kellet telepítenem a gawk, gperf és a texinfo csomagokat.
Most persze nem tudom, hogy a problémákat a frissebb crosstool-ng okozta-e vagy az amd64 architektúra.
Ami még aggaszt, mi lesz a többi library -val? Az ok hogy működik az stdio de mi lesz a többivel. Ráadásul én olyat is használok mint a liboop.
* Én egy indián vagyok. Minden indián hazudik.
http://logout.hu/cikk/a_raspberry_pi_talalkozik_a_felhovel/bevezeto.html
A keresztfordítód olyan gépen lett generálva, amin glibc-2.14 volt, és ezért az arm-linux-gnueabihf-* programok is a glibc-2.14-et keresik futásidőben. Ha az aktuális gépeden régebbi glibc van, akkor nem fog futni. Ha újabb, akkor 99%, hogy igen. Ezek miatt szoktam a saját toolchainjeimet egy viszonylag régi glibc-t használó, 32-bites virtuális gépen fordítani.
Ezen túlmenően az is okozhat vicces perceket, ha pl. 64 bites a host linuxod, de a precompiled toolchaint 32-bites gépen készítették és keresni fogja a 32-bit runtime libeket a gépeden. Ilyenkor telepíteni kell a 32-bites glibc-t meg egy rakás egyebet is a 64-bites rendszeredre.
Csak akkor keresi a keresztforditott program az uj glibc-t, ha annak valamilyen feature-jet hasznalod is a programban. Gyakran keresztforditok amd64-es Wheezy-n alpha-s Lenny-re, sose volt baj vele.
Én arról beszélek, hogy a (cross)toolchain, ami a gépeden fut, az milyen glibc-vel lett fordítva. Az, hogy a keresztfordított program melyik glibc-t/uclibc-t/eglibc-t/newlib-et stb. fogja használni és annak milyen verzióját, megint egy másik kérdés. A célgépen is megfelelő libc kell, hogy fusson a keresztfordított program.
Igazad van, de szerintem az OP-nek a keresztforditott programmal volt baja, a cross-compilerje mukodott.
Próba a szokásos "Hello world", hiba:
"version 'GLIBC_2.14' not found (required by ... arm-linux-gnueabihf-gcc-4.8.3)
Az arm-linux-gnueabihf-gcc-4.8.3 PC-n fut, nem? Akkor miért a target glibc-t kellene használnia? :)
Mondasz te valamit... :-)
Nem. Az első teszt "arm-linux...gcc -v" már itt elvérzik a glibc 2.14 verzióját hiányolja.
* Én egy indián vagyok. Minden indián hazudik.
Úgy döntöttem kipróbálom a "hivatalos" git toolchain -t.
Gond nélkül fut, a "Hello world" lefordítása csont nélkül lement, működik. Kipróbáltam néhány apróságomat is azokkal sem volt gond.
Aztán elővettem az egyik kedvenc kis vackomat (egy egyszerű kis sms szerver), ez már használja a liboop -ot és a postgresqlt is piszkálja, amit anno az ecpg -vel írtam meg.
Először egyszerűen fogtam a liboop néhány modulját és az includokat bemásoltam a megfelelő területre a toolchainen belül - le is fordult gond nélkül. Aztán elkezdtem piszmogni az ecpg -vel és itt már nagyon sok mindent kellet volna átmásolnom (minden forgatásnál újabb és újabb dolgok jöttek elő). Elkezdtem google -zni és találtam egy ilyet:
http://stackoverflow.com/questions/19162072/installing-raspberry-pi-cro…
A javasolt mintapéldát simán lefordítottam, de az én kis app -om még mindig ott tart, hogy nem találja az oop.h include fájlt :(
Most a cmake dokumentációját túrom de egyre kevésbé értem mi lehet a gond, úgy hívom meg ahogy a példa is mutatja, csak a directory kicsit más:
cmake -D CMAKE_TOOLCHAIN_FILE=$HOME/rpi/tools/rpi.cmake ../
A cmake doksiban (cmake.org) nem is találok olyat, hogy "CMAKE_TOOLCHAIN_FILE". A net tele van valami hibaüzenettel, de nálam nem panaszkodik, legenerálja a Makefile -t. Belenéztem a Makefile -ba de nyoma sincs a "rootfs" -nek ahova bemásoltam az aktuális PRI dolgokat. Pedig ottvan, hogy "SET(CMAKE_FIND_ROOT_PATH $ENV{HOME}/rpi/tools/rootfs)" de mintha nem is látná :(
Nem tudom mi lehet a baj. Van valami ötlet? Használt valaki ilyet?
* Én egy indián vagyok. Minden indián hazudik.
Ha nem túl nagy projekt, akkor magán a pi-n is simán fordíthatod. Egy kernelfordítás is csak valami 6 órába telik. A memória konfigot érdemes úgy állítani, hogy a gpu-nak a legkevesebb legyen. Ha kell swap akkor egy mobilwinyót érdemes rákötni és arról felcsatolni.
Köszönöm! Már nem tudom hányszor fordult meg ez a fejemben.
Azonban most már nem adom fel. Biztos vagyok benne hogy valmi triviális hibát vétek valahol, de nem tudok rájönni/meglátni.
A cmake önmagában is érdekes de lehet hogy kisebb projektekhez elég a nativ make, csak valahogy a library -kat és az includokat kell mellé rakni.
* Én egy indián vagyok. Minden indián hazudik.
Szia!
Esetleg használd a buildroot által generált toolchain-t.
Nem kell teljes busybox környezetet fordítanod,
make raspberrypi_defconfigbeállítja az architektúrát,make menuconfig-al finomítod, aztánmake toolchain-el leszedi a neked tetsző gcc/binutils/headers/libc-t, és lefordítja.Debian-on teljesen jól működik. http://buildroot.uclibc.org/downloads/manual/manual.html#_using_the_gen…
Üdv,
S.
Kösz! Érdekes lehetőség, ráadásul előremutató, hiszen a következő lépés lehet egy "kopasz" SBC rendszerének felépítése - ezzel ezt is meg lehet oldani. Ráadásul jóval egyszerűbbnek tűnik mint az ng-csrosstools -ra alapuló rendszer. Viszont ez a LFS - Linux from Scratch megoldás.
Nem tudom mennyire lesz kompatibilis a raspbiannal az eredmény. A raspbian "odaadja" a saját maga által használt eszközt, így azt hiszem
ezt kell használni megérteni. A cmake nem is biztos hogy kell hozzá. A feladat valójában redukálható lenne arra, hogyan adjam meg a compilernek az include fájlok helyét és a linkernek a library -k helyét a fordításkor.
Azt hiszem a cmake dolgot félreteszem és inkább ezeknek járok utána. Régen ezt a kis app -ot egy sima (alig egy oldalas) Makefile segítségével fordítottam, ezt kell átfaragni.
* Én egy indián vagyok. Minden indián hazudik.
Éreztem hogy itt valami egyszerű, triviális hiba van. A hibe, hogy a cmake -t akartam használni - ezt írta a példa. A jó öreg gcc dolgait megvizsgálva, van egy jó kis opció --sysroot=dir itt szépen beállítottam a bemásolt rpi könyvtárak útvonalát, az én esetemben /home/tovis/rpi/tools/rootfs és a kis programom csont nélkül lefordult :D
Az eredeti "nativ" makefile mindössze abban változik, hogy le kell cserélni a compilert és mindenütt beállítani a --sysroot= ot, ennyi.
Azért még ki fogom próbálni a 32 bites Wheezy distrót. Nem is értem, hogy lehet, hogy a Squeeze -n kell Wheezy -t fordítani.
Ki kell próbálni a c -ben íródott GPIO piszkáló program csomagot, ős az AD konverteremhez is van valami kód (ráadásul olyat kaptam amin van vlmi EEPROM is). Szóval hosszú a todo lista.
* Én egy indián vagyok. Minden indián hazudik.