Tentiamo di compilare la Toolchain 3.4.2 su Mac OS X

Non mi esprimo perché in quanto al sistema le mie conoscenze sono inferiori alle tue, però posso solo concordare con te che con lo script ufficiale non c'era verso di compilare. Sul forum di AvrFreaks c'è un utente che tempo fa ha messo un altro script che dovrebbe compilare la toolchain. Ora vedo se ritrovo il link.
Premetto che anche con quello io NON ci sono riuscito :sweat_smile:

EDITO IL POST:

Il thread è questo:
http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=133773

Non è corretto. Questo script lo vedo ora per la prima volta. Tempo fa c'era solo questo:
http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=42631

leo72:

PaoloP:
Rinomina questo.
Rielabora il primo post con tutte le informazioni e poi Leo vedrà di spostarlo in Megatopic. :grin:
Altrimenti le informazioni che hanno permesso di raggiungere il risultato si perdono, se apri altro topic.

Quoto.

Ok, perfetto, allora userò il primo post come riassunto e punto in cui mettere i vari link ed il resto della discussione resterà ... ai posteri ... XD XD XD XD

Guglielmo

MauroTec:
Ho un problema di logica, o meglio devo capire quali intenzioni avesse che ha scritto lo script di Atmel.
In merito al codice che segue:

for d in ld ; do

do_pushd ${d}
        autoreconf || task_error "autoreconf in $d failed."
        do_popd
    done



...

Mmm ... sicuro che gli ritorna il contenuto di ld ??? La help del for dice :

for: for NAME [in WORDS ... ;] do COMMANDS; done
    The `for' loop executes a sequence of commands for each member in a
    list of items.

... e, se provi da terminale : for d in ld ; do echo $d ; done ... ti stampa semplicemente "ld" e NON il contenuto della directory ld ... però ammetto la mia ignoranza ... magari dalla linea comando si comporta in un modo, nello script in un altro ... :roll_eyes:

In ogni caso ... non mi sembra una cosa molto utile fatta in quel modo ... boh :relaxed:

Guglielmo

leo72:
Non mi esprimo perché in quanto al sistema le mie conoscenze sono inferiori alle tue, però posso solo concordare con te che con lo script ufficiale non c'era verso di compilare. Sul forum di AvrFreaks c'è un utente che tempo fa ha messo un altro script che dovrebbe compilare la toolchain. Ora vedo se ritrovo il link.
Premetto che anche con quello io NON ci sono riuscito :sweat_smile:

Leo, non so, non sono totalmente d'accordo ... io NON ho fatto grosse modifiche allo script ... ripeto, ho solo adattato comandi che davano errore su OS X e eliminato una parte di generazione dei commenti ...

Devo dire che la "lampadina" che ha illuminato la strada è stato il comando al post : Tentiamo di compilare la Toolchain 3.4.2 su Mac OS X - #68 by gpb01 - Generale - Arduino Forum che ci ha finalmente fornito i due giusti build system type ed host system type ... da li la strada è stata in discesa :wink:

Continuo a ripetere invece che, il VERO problema, è l'installazione degli innumerevoli pacchetti "al contorno", NON documentati da Atmel che, in continuazione, bloccavano un pezzo dopo l'altro, lo script !!!

Guglielmo

leo72:
EDITO IL POST:

Il thread è questo:
http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=133773

Non è corretto. Questo script lo vedo ora per la prima volta. Tempo fa c'era solo questo:
http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=42631

Ho visitato velocemente il primo link e mi sembra di capire che non prende i pacchetti da Atmel e quindi nemmeno le patch.
Il discorso è che allo script non dovrebbe essere permesso modificare il tree originale dei sorgenti, tutto nei limiti del possibile andrebbe fatto con le patch.
Se tutto fosse fatto con le patch queste essendo altamente portabili potrebbe essere usate su tutte le distro linux per creare i pacchetti rpm, deb ecc

Invece tocca studiare lo script.

Per binutils le cose stanno così:
Bisogna creare un tree di build
avr-binutils-2.23.1
avr-binutils-2.23.1
build

Quindi:

mkdir -p avr-binutils-2.23.1
cd avr-binutils-2.23.1
tar -xjvf /home/maurilio/rpmbuild/SOURCES/binutils-2.23.1.tar.bz2
pushd binutils-2.23.1
#applica tutte le patch per binutils dalla 01 alla 500
sed -i 's/AC_PREREQ(2.64)/AC_PREREQ(2.63)/g' ./configure.ac || task_error "sed failed"
sed -i 's/AC_PREREQ(2.64)/AC_PREREQ(2.63)/g' ./libiberty/configure.ac || task_error "sed failed"
sed -i 's/  \[m4_fatal(\[Please use exactly Autoconf \]/  \[m4_errprintn(\[Please use exactly Autoconf \]/g' ./config/override.m4 || task_error "sed failed"
pushd ld
autoreconf
popd
popd
mkdir -p build
pushd build
../binutils-2.23.1/configure --prefix=/usr --libdir=/usr/lib64 --mandir=/usr/share/man --infodir=/usr/share/info --target=avr --disable-werror --disable-nls --with-pkgversion=avr-binutils-atmel-3.4.2 --with-bugurl=http://www.atmel.com --enable-install-libiberty --enable-install-libbfd
make all-bfd TARGET-bfd=headers
rm bfd/Makefile
make configure-host
make LDFLAGS=-all-static all
make install DESTDIR=percorso della directory di installazione es /home/user/devel/avr
popd

Purtroppo qualcosa non va in make configure-host che nel mio caso configura l'host come x86_64-unknown-linux-gnu.
sconoscita la redhat o fedora che sia, mi sembra una eresia.
Comunque compila e installa correttamente, sempre che non mi sia dimenticato qualche passaggio.

Questione for di prima:
for d in ld ; do è corretto se prevede altre directory es
for d in ld gino pino ecc; do
Come si vede nei comandi precedenti ho usato pushd ld invio e autoreconf invio e poi popd per ritornare alla directory precedente.

Ciao.

@Mauro:
non avevo notato che non scaricava le patch né che non prendesse i pacchetti Atmel.
4 occhi sono meglio di 2 :wink:

leo72:
@Mauro:
non avevo notato che non scaricava le patch né che non prendesse i pacchetti Atmel.
4 occhi sono meglio di 2 :wink:

In ogni caso ricordati che se prende i pacchetti e le patch da Atmel deve sempre usare uno script che più o meno fa le stesse cose dello script originale.

I risultato della compilazione include cose che in arduino e in genere a noi non servono o comunque non li abbiamo mai usate,
tanto che io ad esempio non ho idea a cosa serva avr-ld.bfd, avr-ld è il linker, avr-gprof dovrebbe essere il profiler che aiuta a scrivere codice più efficiente, avr-elfedit è nuovo... che per caso posso editare il .elf?.

Poi ci sono degli header file e delle librerie statiche per sviluppare programmi su arch nativa (cioè PC) da usare per avr, forse per debug ecc.

Chi volesse evitare queste cose in più dopo aver provato i comandi così come sono può riprovare eliminando dal configure:
--enable-install-libiberty --enable-install-libbfd
e dopo basta un solo:
make

Ciao.

Se riesci a replicare uno script per Linux, bene. Perché almeno tutti poi possono compilarsi la toolchain in proprio :wink:

MauroTec:
Se build_platform è diverso da host_platform la variabile 'canadian_cross=true', per avr8 build e host devono essere diverso, mentre nel caso
di AVR32 il compilatore può essere nativo installato in una sd su un embedded board basata su AVR32, oppure può essere un canadian cross compiler.
Peccato che questo non ci dice nulla riguardo al valore che deve assumere 'build_platform', cosa sarà AVR, avr, AVR8, avr8, vediamo se spunta fuori.

Ciao.

no, build platform e host platform sono:
build platform: il SO che compila (mac in questo caso);
host platform: il SO per cui compilare (sempre per mac).

quindi volendo potresti compilare da linux per mac o per windows, o da x86 per 64bit e viceversa...

Se compili, però, per una piattaforma differente potresti non avere modo di fare dei test.
Ad esempio su Windows potrei compilare la toolchain per Mac, ma poi mi appendo perché non potrei provarla. :sweat_smile:

qualche buon anima che testa la si trova sempre :grin:

lesto:
.....
quindi volendo potresti compilare da linux per mac o per windows, o da x86 per 64bit e viceversa...

Te piacerebbe ... come dicono a Roma ... XD XD XD

Su Mac io non ci conterei ... come hai visto le abbiamo provate TUTTE e, qualsiasi cosa metti in -H o in -B diverso da x86_64-apple-darwin12.4.0 ... fa fallire il processo :frowning:

Guglielmo

... per inciso, come ho già segnalato nel topic relativo all'IDE 1.5.x, ... sono assente per una decina di gg ... appena rientro, come d'accordo con Leo, pubblico il tutto in modo ordinato ... abbiate pazienza ... :blush:

Guglielmo

devi avere un sistema adatto alla cross-compilazione... direi di scordartelo su mac. Intendevo che una buon'anima compila da linux per mac x86 e x64

Ho visto adesso l'altro post.
Ti faccio i complimenti qui per non sporcare lì.
:grin: :grin: :grin:

Plovelbio cinese: Chi l'ha dura, la vince.

Si, ok. Potete bannarmi per 72 ore. :roll_eyes: :roll_eyes:

PaoloP:
Ho visto adesso l'altro post.
Ti faccio i complimenti qui per non sporcare lì.
:grin: :grin: :grin:

GRAZIE ... comunque poi servirà l'aiuto di tutti per sistemare i problemi del "core" che vengono fuori con la nuova toolchain ... pgmspace. WiFi, ecc. ecc.

PaoloP:
Plovelbio cinese: Chi l'ha dura, la vince.

... anche ... chi l'ha duro ... :grin: XD :grin: XD :grin: XD ... ok, battutaccia !!!

Guglielmo

Se pubblichi gli errori completi, possiamo darci un'occhiata.

Intanto, posso dirti che a suo tempo ebbi problemi con la funzione delay, che il core Arduino ridefiniva quando era già definita nella toolchain, poi con pgrmem perché erano cambiate le definizioni (ad esempio prog_char era deprecato e bisognava sostituirlo con const PROGMEM char, ecc). C'erano dei problemi anche con i file HardwareSerial.cpp e .h perché il vecchio core usava SIGNAL al posto di ISR per gestire le routine di interrupt, nonché nei file WInterrupts.c e Wiring.c per lo stesso motivo.
Poi a mente non mi viene altro.

Non so se sia attinente all'argomento
--> Redirecting to Google Groups
--> GitHub - arduino/toolchain-avr: The AVR toolchain used by the Arduino IDE