[ << ] [ < ] [ Home ] [ > ] [ >> ]

2. Creare un Cross-Compilatore

• Prologo
• crossdev
• I dettagli della Cross-Compilazione

2.a. Prologo

La prima cosa da sapere sulla creazione di una toolchain è che certe versioni di alcuni suoi componenti non funzionano assieme. Sapere quali siano le esatte combinazioni problematiche è un dato che è in costante mutamento a seconda di come si sviluppa l'albero di portage. L'unico modo sicuro per determinare se una certa combinazione funziona è eseguire crossdev, specificando le versioni dei vari componenti secondo necessità, finché non viene completata con successo la compilazione dell'intera toolchain. Anche a quel punto, la cross toolchain potrebbe generare binari non funzionanti sul sistema di destinazione. Solo avendo pazienza e procedendo per tentativi ed errori si potrà ottenere una combinazione favorevole di tutti i fattori.

Tutti i pacchetti della toolchain sono pensati in modo tale da esser totalmente isolati in base all'architettura di destinazione, per cui non c'è modo che interferiscano con l'ambiente nativo di compilazione. Questo permette di installare cross-compilatori per qualunque architettura si desideri senza intaccare il resto del sistema.

Tuttavia, ci sono alcuni scenari, anche se in diminuzione ogni giorno che passa, che fanno sì che portage richieda o influenzi dei cambiamenti alla root reale. Per mantenere pulita la propria installazione di Gentoo, si raccomanda caldamente che l'installazione di crossdev e tutte le attività di cross-compilazione avvengano dentro ad un chroot di uno stage3 di Gentoo. (È lo stesso chroot usato per installare Gentoo.)

2.b. crossdev

Introduzione

Generare a mano un cross-compilatore era un processo lungo e tedioso. Per questo è stato integrato totalmente in Gentoo! Tramite un'interfaccia chiamata crossdev (installabile con emerge crossdev) emerge verrà eseguito con tutte le variabili d'ambiente valorizzate correttamente ed installerà tutti i pacchetti corretti per generare qualunque tipo di cross-compilatore di cui si ha bisogno. Per prima cosa bisogna installare crossdev.

# emerge crossdev

È consigliabile installare la versione instabile (~arch) di crossdev per ottenere tutte le più recenti correzioni.

In questo documento verrà coperto solamente l'utilizzo basilare di crossdev, tuttavia questo strumento può personalizzare adeguatamente il processo per la maggior parte delle necessità. Eseguire crossdev --help per ottenere alcune indicazioni su come usare crossdev. Ecco alcune delle modalità d'uso più comuni:

(Usare delle versioni specifiche dei pacchetti)
# crossdev --g [gcc version] --l [(g)libc version] --b [binutils version] --k
[kernel headers version] -P -v -t [tuple]
(Usare solamente la versione stabile)
# crossdev -S -P -v -t [tuple]

Installazione

Il primo passo consiste nel selezionare la corretta stringa per il sistema di destinazione. Prendiamo ad esempio che si voglia generare un cross-compilatore per il processore SH4 (SuperH) con supporto alle glibc per Sistema Operativo Linux. Il tutto partendo da una macchina PowerPC.

# crossdev --target sh4-unknown-linux-gnu
-----------------------------------------------------------------------------------------------------
 * Host Portage ARCH:     ppc
 * Target Portage ARCH:   sh
 * Target System:         sh4-unknown-linux-gnu
 * Stage:                 4 (C/C++ compiler)

 * binutils:              binutils-[latest]
 * gcc:                   gcc-[latest]
 * headers:               linux-headers-[latest]
 * libc:                  glibc-[latest]

 * PORTDIR_OVERLAY:       /usr/local/portage
 * PORT_LOGDIR:           /var/log/portage
 * PKGDIR:                /usr/portage/packages/powerpc-unknown-linux-gnu/cross/sh4-unknown-linux-gnu
 * PORTAGE_TMPDIR:        /var/tmp/cross/sh4-unknown-linux-gnu
  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _
 * Forcing the latest versions of {binutils,gcc}-config/gnuconfig ...                          [ ok ]
 * Log: /var/log/portage/cross-sh4-unknown-linux-gnu-binutils.log
 * Emerging cross-binutils ...                                                                 [ ok ]
 * Log: /var/log/portage/cross-sh4-unknown-linux-gnu-gcc-stage1.log
 * Emerging cross-gcc-stage1 ...                                                               [ ok ]
 * Log: /var/log/portage/cross-sh4-unknown-linux-gnu-linux-headers.log
 * Emerging cross-linux-headers ...                                                            [ ok ]
 * Log: /var/log/portage/cross-sh4-unknown-linux-gnu-glibc.log
 * Emerging cross-glibc ...                                                                    [ ok ]
 * Log: /var/log/portage/cross-sh4-unknown-linux-gnu-gcc-stage2.log
 * Emerging cross-gcc-stage2 ...                                                               [ ok ]

Test Veloce

Se tutto è andato come previsto, si dovrebbe avere un compilatore nuovo fiammante sulla propria macchina. Facciamo una prova!

$ sh4-unknown-linux-gnu-gcc --version
sh4-unknown-linux-gnu-gcc (GCC) 4.2.0 (Gentoo 4.2.0 p1.4)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ echo 'int main(){return 0;}' > sh4-test.c
$ sh4-unknown-linux-gnu-gcc -Wall sh4-test.c -o sh4-test
$ file sh4-test
sh4-test: ELF 32-bit LSB executable, Renesas SH, version 1 (SYSV), for GNU/Linux 2.6.9, dynamically linked (uses shared libs), not stripped

Se il comando crossdev fallisse, saranno comunque a disposizione i log per analizzare il problema che si è verificato. Se non si è in grado di risolvere il problema, aprite pure un bug sul bugzilla di Gentoo. Per maggiori informazioni visitare la pagina dei Contatti.

Disinstallazione

Per disinstallare una toolchain, è sufficiente usare l'opzione --clean. Se la sysroot è stata modificata a mano, vi verrà domandato se cancellarne il contenuto, per cui potreste volere mettere in pipe yes | al comando.

# crossdev --clean sh4-unknown-linux-gnu

Nel caso non lo si abbia già notato, cancellare tutti i file contenuti nella directory /usr/CTARGET/ è completamente sicuro.

Opzioni

Ovviamente crossdev può fare molte altre cose, per scoprirle, basta lanciare crossdev --help.

2.c. I dettagli della Cross-Compilazione

Introduzione

Generalmente ci sono due strade percorribili per generare il proprio compilatore. La via "maestra" e l'oscura scorciatoia.

La via "maestra" è:

1. binutils
2. header del kernel
3. header delle libc
4. gcc stage1 (solo c)
5. libc
6. gcc stage2 (c/c++/etc...)

L'oscura scorciatoia invece è:

1. binutils
2. header del kernel
3. gcc stage1 (solo c)
4. libc
5. gcc stage2 (c/c++/etc...)

Molte persone seguono la scorciatoia perche la generazione degli header delle libc richiede molto tempo, specie su macchine lente. Inoltre installare gli header del kernel e/o delle libc senza un cross-compilatore funzionante potrebbe esser una scocciatura. Ricordate però che se si cerca aiuto sui cross-compilatori, il progetto upstream non vi offrirà supporto se avrete utilizzato la scorciatoia.

La scorciatoia inoltre richiede uno stage1 "menomato". Dal momento che si sta compilando senza gli header, non è possibile abilitare le varie opzione della sysroot né è possibile compilare correttamente le librerie del gcc. Questa situazione può essere accettabile solo se si usa lo stage1 per compilare la libreria C e il kernel, per tutto il resto sarà necessario un compilatore basato su sysroot.

Di seguito verrà descritta solo la via "riconosciuta", i passi da fare comunque sono praticamente gli stessi. Per la scorciatoia sarà sufficiente applicare qualche patch supplementare al gcc.

Sysroot

La cross-compilazione avverrà usando il metodo della sysroot. Ma cosa si intende precisamente quando si parla di sysroot ?

Dalla documentazione del gcc:
Dice al GCC di considerare dir come la radice (NdT. root) di un'alberatura contenente il filesystem di root del sistema operativo di destinazione. Gli header del sistema di destinazione, le librerie e gli oggetti a run-time saranno ricercati al suo all'interno.

La directory radice solitamente viene posizionata in /usr/$CTARGET .

/usr/$CTARGET/
|-- bin/
|-- lib/            librerie di runtime critiche (libc/ldso/etc...)
`-- usr/
|-- include/    header per lo sviluppo
|   |-- linux/      come il kernel linux
|   `-- asm/        come le dir. specifiche per ogni architettura
`-- lib/        librerie di runtime / sviluppo non critiche

Come si può notare, è una configurazione analoga alla / , solo che si trova in /usr/$CTARGET. Questa scelta non è ovviamente accidentale, ma pensata di proposito così da rendere semplice la migrazione di applicazioni e/o librerie da /usr/$CTARGET alla / sull'architettura di destinazione. volendo, è possibile utilizzare /usr/$CTARGET come NFS root pronta all'uso!

Binutils

Prelevare l'ultima versione del pacchetto binutils e scompattarlo.

L'opzione di configurazione --disable-werror è usata per evitare che la compilazione delle binutils fallisca per via dei warning. Caratteristica molto utile per gli sviluppatori, molto problematica invece per gli utenti.

$ ./configure \
     --target=$CTARGET \
     --prefix=/usr \
     --with-sysroot=/usr/$CTARGET \
     --disable-werror
$ make
$ make install DESTDIR=$PWD/install-root

Il motivo per cui le binutils vengono installate nella directory install-root è per permettere la rimozione di componenti di cui non si ha bisogno. Ad esempio, una normale installazione creerà /usr/lib/libiberty.a che non deve però far parte del sistema in uso. Va perciò fatta prima un po' di pulizia:

$ rm -rf install-root/usr/{info,lib,man,share}

Installare quindi quanto rimasto :

# cp -a install-root/* /

Header del kernel

Prelevare l'ultimo pacchetto del kernel e scompattarlo. Gli header possono essere installati in 2 modi: ripuliti o grezzi. La prima è chiaramente migliore (richiede però una versione recente del kernel Linux), ma verranno illustrate brevemente entrambe.

$ yes "" | make ARCH=$ARCH oldconfig prepare
# mkdir -p /usr/$CTARGET/usr/include
# cp -a include/linux include/asm-generic /usr/$CTARGET/usr/include/
# cp -a include/asm-$ARCH /usr/$CTARGET/usr/include/asm

# make ARCH=$ARCH headers_install INSTALL_HDR_PATH=/usr/$CTARGET/usr

Header delle libc di sistema

Prelevare l'ultimo pacchetto delle glibc e scompattarlo. Le Glibc sono piuttosto esigenti, per questo andranno compilate in una directory differente da quella dei sorgenti.

$ mkdir build
$ cd build
$ ../configure \
     --host=$CTARGET \
     --prefix=/usr \
     --with-headers=/usr/$CTARGET/usr/include \
     --without-cvs \
     --disable-sanity-checks
# make -k install-headers install_root=/usr/$CTARGET

Purtroppo le glibc non sono perfette e richiedono che alcune operazioni siano fatte a mano:

# mkdir -p /usr/$CTARGET/usr/include/gnu
# touch /usr/$CTARGET/usr/include/gnu/stubs.h
# cp bits/stdio_lim.h /usr/$CTARGET/usr/include/bits/

GCC Stage 1 (solo C)

Prima di tutto bisogna fare in modo che il gcc trovi gli header delle libc.

# ln -s usr/include /usr/$CTARGET/sys-include

Quindi prelevare l'ultima versione del pacchetto gcc e scompattarlo.

$ mkdir build
$ cd build
$ ../configure \
     --target=$CTARGET \
     --prefix=/usr \
     --with-sysroot=/usr/$CTARGET \
     --enable-languages=c \
     --disable-shared \
     --disable-checking \
     --disable-werror \
     --disable-libmudflap \
     --disable-libssp \
     --disable-libgomp \
     --disable-libssp
$ make
$ make install DESTDIR=$PWD/install-root

Come le binutils, anche il gcc crea dei file che non ci interessano.

$ rm -rf install-root/usr/{info,include,lib/libiberty.a,man,share}

Installare poi quanto rimasto (tutto dovrebbe finire nelle directory del CTARGET specificato, senza sovrascrivere alcun file del sistema in uso):

# cp -a install-root/* /

Libc di Sistema

Eliminare la vecchia cartella di compilazione del gcc e ricrearla.

$ rm -rf build
$ mkdir build
$ cd build
$ ../configure \
     --host=$CTARGET \
     --prefix=/usr \
     --without-cvs
$ make
# make install install_root=/usr/$CTARGET

GCC Stage 2 (Tutti i frontend)

È giunta l'ora di compilare un GCC completo. Scegliere i frontend al compilatore d'interesse; per semplicità si selezioneranno solo C e C++.

$ ./configure \
     --target=$CTARGET \
     --prefix=/usr \
     --with-sysroot=/usr/$CTARGET \
     --enable-languages=c,c++ \
     --enable-shared \
     --disable-checking \
     --disable-werror
$ make
# make install

File Core Runtime

Ci sono diversi file core runtime casuali di cui si vorrebbe conoscerne la funzione. Ecco una breve spiegazione.

L'ordine generale in fase di linking:

... crt1.o crti.o crtbegin.o [-L paths] [user objects] [gcc libs] [C libs] [gcc libs] crtend.o crtn.o

[ << ] [ < ] [ Home ] [ > ] [ >> ]

I contenuti di questo documento sono rilasciati sotto la licenza Creative Commons - Attribution / Share Alike.