[kalvis]

Üritan ühele SAT boxile (Prismcube) krosskompilaatorit teha, et saaks sinna kompileerida USB draiveri. Boxil endal on Angstrom Linux 2.6.34, kahjuks kõike minimaalselt (arendusvahendeid loomulikult mitte)
Proseks on 1 GHz ARM (NPX) armv7a (vist ilma FPU-ta ja muudeta, isegi googel ei tea kas on või ei ole), kuna Angstrom linux on arm-linux-gnueabi sättega. Boxi soft on kompileeritud gcc 4.7.2 versiooniga.
Box kasutab eglibc versiooniga 2.16, mingi crypt add-on ja BIND-8.2.3-T5B

Krosskompilaatorit teen windows keskkonnas Cygwin64 (uusim mis alla tõmmatud sai). Võibolla on see vale aga tõmbasin alla uusima gcc 8.2.0 ja binutilsi lähtekoodid, Linux kernel 2.6.34 (mida uname väitis) headerid ja need õnnestus tüüpsätetega kokku kompileerida. --target=arm-linux-gnueabi.

Järgmisena asusin eglibc (2.13) asju kompileerima. Kasutasin glibc kompileerimise õpetuse varianti (st. --host=--target sättega, kasutatakse cygwini enda gcc)) kuna see meetod tundus mugavam ja õigem olevat. /configurest kaugemale ei jõudnud, sest väitis cygwini make 4.2.... liiga vana olevat, ometigi on see parima numbriga mida pakutakse. Küsimusi on kas liiga palju või vähe või valesti, ei oskagi midagi teha.

Üritan:
1. Kas peaksin grosskompilaatorilele tegema gcc-4.7.2 versiooniga millele on selle boxi soft kompileeritud? Või on see gcc 8.2.0 liiga vinge numbriga?
2. https://www.gurucoding.com/en/rpi_cross_compiler/building_eglibc_cygwin_vm.php kasutab kompileerimiseks juba tekkinud krosskompilaatori gcc (mis on vaid first stage, ehk tegelikult mittetöötav kuigi kood on olemas). Kuna selle make võib uus olla siis kas sellepärast temal see õnnestub? On küll käsitööd rohkem aga kas tuleks codeguru näide järgi proovida
3. Kas üldse on eglibc librari asju vaja kompileerida kui need on boxis olemas? saan ju kõik failid tagasi tõmmata või ssh root kataloogi ette anda. Või on need krosskompilaatoril hübriidid ja tuleb kindlasti tema oma kasutada ja lähtekoodist kompileerida?
4. Või kas saab otse gcc boxi sisse kompileerida, seal on 250 GB ja 1 GHz prose olemas vaja oleks vaid gcc ja mõned arendusvahendid.

Angstrom linux (ja prismcube) ise on ajast ja aega juba maas, seega sealt boxi lisatarkvara tõmmata ei saa.

Plaan B on ka olemas, selleks on kasutada Raspberryt koodi kompileerimiseks (äkki on uuem make olemas) aga Cygwin oleks justkui mugavam.

[Supiplex]

Cygwin on üsna habras asi, ma seal peal cross-compile tööriistu ei tahaks mingi hinna eest käima hakata ajama. Tekivadki müstilised probleemid, nagu see et automake ei saa aru kuhu ja mis make tegelikult paigaldatud on.
Kui vähegi võimalik varasta kusagilt mingid gcc binaarid mis su karbi peal käima lähevad ja kompileeri seal.

[kalvis]

Hakkasin otsima ja vist midagi leidsin.
Nimelt leidsin Angstrom linuxi mingi pärapõrgu distriputsiooni. Just armv7. ja seal on eglibc ja gcc 4.5 saadaval ja muudki
opkg õnnestus isegi aadress söödavaks teha. hakkas alla tõmbama aga siis tuli miski ebameeldimine: update-alternatives: Error: cannot register alternative chfn to /usr/bin/chfn since it is already registered to /usr/sbin/chsh
Homme tegelen veateatega edasi...

[klf]

Tõsine ettevõtmine. :-)

3. USB draiveri kompileerimiseks on sul arvatavasti vaja (peale kerneli src) ainult toolchain'i ehk siis kompilaatori pakki.
1. Kasuta gcc versiooni, mis kõige vähem mudimist vajab. 4.7 on hea küll.
2. Crosscompile on üldse üks habras värk.... Soovitaks alustada sellisest kohast nagu crosstool-ng.
See sisaldab hulganisti patche ja bugfix'e mis erinevate gcc, eglibc versioonide otsa lastakse. Konfigureerid seda läbi menüü, üsna sarnane kerneli enda menuconfig'iga.
Sellega ehitad oma toolchaini valmis ja installid boxile kuhugi /opt alla vms. Kui ilmneb probleem, konfid oma toolchaini ringi ja proovid jälle.

Muide, kas sul on boxi kerneli config teada? /proc/config.gz eksisteerib?

[kalvis]

Üritasingi enne crosstool-ng kasutada. ct-ng ise tegi valmis aga siis müstiline ncurses .h failis C keele enda kompileerimise error. Viga on lähtekoodis ja mingites failide enda kompileerimises (kui seal paarisajas failis tüübid omavahel ei kattu sõltuvalt jooksvast konfigurest siis tekib selline viga).
Tegelt on windowsis isegi mingw ja sellega sain ka väga kaugele (GCC1 stage ja binutilsi tegi ära). Point aga oli selles, et mingw lõppes õpetus peale gcc esmakore kompileerimist ära ja nuputa ise kuidas eglibc kompileeritud saad. Asi oli selles, et mingw tuli uskumatult palju petma hakata ja siis veel rohkem tuli lähtekoode petma ja patchima hakata, et mis imekeskond see mingw on...
Momendil pole ühtegi piisavalt elujõulist ronti kah, et Ubuntu peale lasta ja ainult selle projekti jaoks kasutada. Seejuures windooza on tööarvutis (ja sinna ei lubata iial Ubuntut panna) ja asi siis korraks paar käsku aknakesse kirjutada ja las kompileerib. Kahju, et see Cygwin nii äbarik on.

Krosskompileerimise mõte oli aga laialdasem - nimelt on soov paljudele eritüübilistele satiboxidele USB vidinate draivereid lisada, et sellest võidaksid kõik. Kui üks õnnestub siis õnnestuvad teised ka. Asja mõte on teha satboxidele DVB-T2/C tugi.
Tõenäoliselt saan selle prismcube native gcc tööle, omaette teema on kui draiveri kompileerimine lahti läheb. Ma teen siis oma teema kui selles küsimusi tekib.
Kui aga kellelgi on just Cygwinis õnnestunud kogemusi krosskompileerimise osas siis viiteid võib anda. Ma tahaks ikkagi mistahes kombinatsioonis krosskompileerimise tööle saada. Kasvõi x86 linux arvutile või mis iganes. Tõenäoliselt vahetan lähiajal eglibc standard C glibc vastu ära ja proovin sellega. Äkki on ähem nõudlikum.

[Supiplex]

See, kas projekti X cross compile toimib host Y otsas target Z vastu sõltub sellest kas projekti X arendaja on viitsinud oma build süsteemi ja koodi selliselt ehitada, et see toimiks sinu poolt soovitud kombinatsioonis. See päris tasuta ei tule. Kui arendaja ei viitsinud ja sina viitsid, siis oled sina nüüd selle projekti arendaja

Ma kahtlustan, et gcc ja *libc arendajad on oma porditavuse osas kõvasti vaeva näinud, kuid nimelt cygwini osas jään siiski skeptiliseks. See on nii habras häkk, et kipub iseenesest katki minema. Ma võtaks mingi virtuaalse Linuxi purgi ligi.

[Adebisi]

Windows 10 all on muidu Windows Subsystem for Linux, äkki kärab paremini kui Cygwin.

[kalvis]

Hea uudis on see, feeds.angstrom.org allt saadav gcc_4.5 hakkas prismcubesse installides tööle ja kompileerib koodi.
Tõsi installimine ei läinud valutult, .ipk manager tahab siin mingeid naljakaid vigu visata (eespool toodud), et miskid asjad on ja miskid lingitakse mujale, kahjuks googlega ei saanudki sotti mis on vale. Aga igaks juhuks tegin lisakataloogi /opt ja praegu maandus gcc oma binaaride (opt/usr) ja libraritega (opt/lib) sinna.
gcc töötab.

hello.c kompileerides aga ei leia librareid ülesse (tahab saada libmpc.so.2 mis on seal opt/lib kataloogis olemas) püüdsin LD_LIBRARY_PATH ja samasse kataloogi seda kopeerida, ikka ei leia seda faili, kuigi olemas. (ühtegi süsteemi muutujat see .ipk manager ei tee ega aktiveeri)

Küsimus:
kuidas seda gcc ikka kõige paremini nüüd konfigureerida, on kuskil õpetus. Hea oleks kui saaksin siiski süsteemist lahku et kõik C asjad oleksid edaspidi (hdd /mnt/hdd0/opt; ..opt/lib ja ..opt/usr jne. kataloogis, ma ei tahaks väga muu süsteemifailidega kokku lasta. See kehtib ka teiste arendusvahendite kohta, binutils, make, cmake ja mõned muud. Et ainult lõppkood mis oleks testitud, jõuaks flash mällu. box kasutab busybox failide hoidmiseks.
Samas kui ma tahaksin et kasutaks just süsteemi executable librarei (asuvad/bin /usr /lib ja /usr/bin ja /usr/lib siis kuidas oleks ettevaatlik majandada. Need asuvad flash mälus ja ei tahaks sinna katsetamise asju panna. Kas symbol linkidega või kuidas just ohutult teha.

Teine küssa oleks, millised arendusvahendeid otsida, et oleks piisav kompileerimise pakett. (make, cmake, perl, python, binutils on olemas)

[Supiplex]

[kalvis]

Kataloogindusega sain korda.
https://gcc.gnu.org/onlinedocs/gcc-4.7.0/gcc/Environment-Variables.html

Linkisin /usr/lib puuduolevad failid (et flashi säästa, seal polnud neid C librareid) ja sain kaugemale edasi. Nimelt oli valdavas enamuses see kataloog paksult linke täis, mõned üksikud olid ka õiged failid.
sain küll nüüd konkreetselt hello.c kohta "cc1: internal compiler error: illegal instruktion" veateate ja see vist on puuduvast includest (muidugi kõik failid pole veel lingitud). Mul pole veel ühtegi gcc include kataloogi (see tuleb eraldi alla tõmmata!)

Tundub et asi laheneb (tuleb included ka saada).

Niipalju sain teada,et nimetatud gcc on ise krosskompileeritud x86-pc-linux peal, et kui linux masina saan, küll saab ka krosskompilaatori kunagi seal ka tööle.

Momendil case closed