[Frissítve] AVR-GCC régebbi toolchain - Windows és Linux bináris eltér

Fejlesztés

Sziasztok!

Letöltöttem az AVR-GCC 3.3.2-es, Linux alá fordított verzióját.
Mivel meglévő projekthez ez volt használva, nekem is ezt kellene most.

Ez elvileg statikusan linkelt binárisokat tartalmaz, viszont nem tudom futtatni a rendszeren.
Debian Jessie van fent és 4.1.x kernel.

Ezt az üzenetet kapom:
"unexpected reloc type in static binary"

Szerintetek min csúszik el a dolog és hogyan tudnám működésre bírni?

Minden segítséget előre is köszönök.

  • 1694 megtekintés

( tovis v | 2015. 10. 07., sze – 09:31 )

Sokszor futottam bele ilyesmibe :(
Nem tudom mi a feladat/cél, de lehet megéri előhúzni a fejlesztés idejében aktuálisan használt disztrót. Egy átlagos Debian verzió 8G partíción simán elél.
Aztán ha teljesült a határidő, lesz(?) idő a függőségekkel piszmogni.

OFF: Ha (előreláthatóan) csak néhány sor kódot kell javítani/módosítani, érdemes visszanyúlni a fejlesztési időben használt környezethez - könnyebb reprodukálni. Ha viszont új fejlesztést indítasz a régi alapokon, akkor az aktuális környezethez érdemes igazodnod - vagyis az aktuális disztróhoz illesztett fordítót kell használni.

* Én egy indián vagyok. Minden indián hazudik.

Az előző disztró Windows, és sajnos nem néhány sort kell módosítanom. :S
...tehát jó volna megtartani a kényelmet is...

Mivel lehet vajon haragban?
A kernel nem tetszik neki?

Egyébként chroot-ban megpróbáltam Squeeze-t és Wheezy-t, ill. Ubuntu 10.04 LTS-t is (próbáltam a régebbiek felé visszamenni, ezért lett az Ubuntus próba 10.04)... ill. késő volt, és nem vagyok biztos benne, hogy mindig 32-bites rendszer volt a chroot-ban... a saját rendszerem és a kernel x64-es.

Reméltem, egy chrootolt környezet felépítése elég lesz (bár ez ugye statikusan linkelt lenne).
Újrafordításra is gondoltam, de az Atmelnél csak patchek vannak fenn, és elő kellene keríteni hozzá a kiindulási alapot az összes komponensből... :S

Op.rendszer virtualizáció sem túl ideális, bár Windows 7 licence van a géphez - nincs viszont telepítve és virtualizálni sem biztos, hogy megengedett... :S

Ránéztem a Squeeze -re - az is már 4.3 gcc-avr.
Mivel lehet haragban - rengeteg mindennel. Ráadásul ha (valahogy) túljutsz a gcc-avr futtatásának problémáján akkor ott lesz az avr-libc meg ki tudja mi más.
"Újrafordításra is gondoltam, de az Atmelnél csak patchek vannak fenn" - ez most még mindig a gcc-avr?
Szerintem rossz irányból szaladsz neki. Végy elő egy modern gcc-avr -t és a régi forrást javítsd. Gondolj abba bele, hogy mi lesz mondjuk megint 5 év múlva amikor ismét elő kell venni ezt a cuccot!?
Amit esetleg még megpróbálhatsz egy wine amire feltelepíted a régi avrstudiót, a windowzos 3.3 gcc-avr -el. De szerintem a forrás aktualizálása jobb megoldás.

* Én egy indián vagyok. Minden indián hazudik.

Igen, azt szeretném megoldani.
Modern gcc-avr-rel az a "baj", hogy másik gépen, másik projektet is érintene, és hibalehetőséget (amit tesztelni kell) nem szeretnék vinni a rendszerbe - nem járható, mert nekem kellene kompatibilisnek maradnom. :S

Nem tudom, mi alapján verziószámoznak a disztribúcióban... elvileg (ha hinni lehet a file-névnek) ez is 4.5.1-es GCC-re épül, a toolchain verziója 3.2
Az avr32 toolchain-ben lévő fordító 4.4.3-mas GCC-re épül, és 3.3.2_321-es a toolchain - ráadásul ez rendesen fut is (csak ugye más kontrollerekhez van)...

Wine-vel próbáltam. Az AVR Studio szépen fut, de fordítás során, az egyik GCC-híváskor elszáll.

Kicsit nehezítve van a pálya :(
Van nálam egy XP -re telepített 4.19 AVR Studio 4 de magát az avr-gcc.exe ... egy Arduino telepítésben találtam 4.8.1 ?
" ... az egyik GCC-híváskor elszáll." - így érthető - érdekes ha elindítja Linux alapon wine alól a cygwin -t :)
Mivel a Linuxos megoldásokat - nekem úgy tűnik - kimerítetted, marad hogy kerítesz egy winXP -t és arra raksz valami régi AVR Stúdiót. Az előző fejvesztés is gondolom így működött.
(Ilyenkor lenne jó, ha az elődöd feljegyezte volna milyen hokedlin is fejlesztett)

* Én egy indián vagyok. Minden indián hazudik.

( VaZso v | 2015. 10. 20., k – 21:53 )

Nagy nehezen sikerült találnom egy működő 3.3.2_485-as verziót - egyrészt ez X64-es, mint a rendszer, másrészt az Atmel archive-jában fent lévő tar.gz hibás.
Egy fórumon találtam közvetlen linket ugyanennek a .zip-es verziójára, az működik, bár a végrehajtható jogosultságokat kézzel kellett helyreállítanom.

A működik alatt azt értem, hogy fordul a kód, le tudom tölteni az AVR-be, és fut a program is, látszólag jól... de...
...de nem bitre azonos kódot fordít, mint a Wines AVR-GCC.

Az Atmel archív oldalán fent lévő anyagokat böngészve szomorúan tapasztaltam, hogy a hasonló verziójú avr-gcc-ből egyszerűen nincs olyan verzió fent, ami egyaránt Windowsra és Linuxra is letölthető, tehát nem tudtam tökéletesen azonos verziószámú fordítóval próbálkozni.
Ellenben Windowsra feltettem a 3.3.0.710-as verzió helyett egy 3.3.1.1020-eset, ez bitre azonos kódot generált.

Linuxon viszont 3.3.2.485-ös verzióm van.
Az ezzel generált kód program-, ill. adatmemória foglalása azonos a Windowsos fordítóéval, de ugye nem bitre azonos.

A .map file-okat nézegetve úgy tűnik, az egyes függvények, ill. szekciók helyfoglalása azonos, de az egyes részek konkrét címe viszonylag hamar eltér - minden megvan és minden sorra kerül, de más sorrendben követik egymást az egyes függvények, ill. programterületek.

?? Más sorrendben dolgozná fel a projekt fájljait? ??

Min kellene változtatnom, hogy teljesen azonos bináris legyen a végeredmény?
Hogyan lenne érdemes elindulni, esetleg milyen beállításokat nézzek meg?
Linuxon Eclipse Mars környezet alá van telepítve.

Wines fordításból kiragadott sor: 

avr-gcc  -mmcu=atxmega256a3 -Wall -gdwarf-2 -std=gnu99     -DF_CPU=32000000UL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -MD -MP -MT uart_1.o -MF dep/uart_1.o.d  -c  ../uart_1.c

Linuxos fordításból kiragadott sor: 

avr-gcc -Wall -Os -fpack-struct -fshort-enums -std=gnu99 -funsigned-char -funsigned-bitfields -gdwarf-2 -mmcu=atxmega256a3 -DF_CPU=32000000UL -MMD -MP -MF"uart_1.d" -MT"uart_1.o" -c -o "uart_1.o" "../uart_1.c"

Esetleg valakinek volna ötlete?

( VaZso v | 2015. 10. 20., k – 23:23 )

...azért arra még kíváncsi leszek, másik gépen (eltérő rendszeren, eltérő processzorral), de ugyanezzel az AVR Studio-val és toolchainnel fordítva milyen kimenetet produkál.

Nem vagyok biztos abban, hogy bitre azonos lesz, sőt.
Tartok tőle, hogy ennek a hasonlítgatásnak nem sok értelme van.