Avant tout, allez télécharger les paquetages sources suivants :
C'est les versions courantes recommandées. Des versions plus vielles peuvent ou ne peuvent pas fonctionner. Si vous essayez d'utiliser des versions plus vielles, s'il vous plaît n'envoyez pas de rapport de bugs ; nous n'y attacherons aucune importance. Lors de l'installation, s'il vous plaît, installez tous dans l'ordre : binutils, egcs puis glibc. A moins que vous ayez des versions plus vieilles déjà installé, changer l'ordre fera échouer le processus. La description suivante de l'installation mentionne un nombre de patches que vous pouvez prendre des paquets SRPM respectifs sur ftp.linux.sgi.com. Cependant, depuis que ces paquets SRPM ont pour but d'être compilé nativement, il n'est pas possible de juste les recompiler.
Pour l'installation, vous aurez à choisir un dossier pour l'installation. Je ferais référence à ce dossier ensuite avec <prefix>.Pour ne pas avoir de problèmes, il vaut mieux la même valeur pour <prefix> que pour votre gcc natif. Par exemple, si votre gcc est installé dans /usr/bin/gcc alors choisissez /usr pour <prefix> Vous devez utiliser la même valeur <prefix> pour tous les paquetages que vous allez installer.
Pendant la compilation, vous aurez besoin d'environ 31 Mb d'espace disque pour binutils; pour l'installation, vous aurez besoin de 7 Mb d'espace disque pour une partition sur <prefix> La construction d'egcs requiert 71 Mb et l'installation 14 Mb. La librairie GNU libc a besoin de 149 Mb d'espace disque durant la compilation et 33 Mb pour l'installation. Notez que ces nombres sont juste une indication et devrait différer significativement pour différents processeurs et architectures de système d'exploitation.
Une des caractéristiques spéciales de l'architecture MIPS est que tous les processeurs excepté le R8000 peuvent être configuré pour fonctionner soit en mode big endian soit en mode little endian. L'ordre des octets signifie la manière dont le processeur garde les nombres de plusieurs octets en mémoire. Les machines big endian garde l'octet de poids fort au bas de l'adresse tandis que les machines little endian le garde à l'adresse la plus haute. Pensez que c'est comme si vous écriviez des nombres de plusieurs chiffres de gauche à droite et vice versa.
Dans le but d'initialiser le compilateur croisé correctement, vous devez connaître l'ordre des octets de la cible du compilateur croisé. Si vous ne le savez pas, vérifiez la section "Plate-formes matérielles" pour l'ordre des octets des machines.
Plusieurs paquetages basé sur autoconf supporte plusieurs architectures différentes et plusieurs système d'exploitation. Dans le but de faire la différence entre toutes ces configurations, les noms sont construits comme suit <cpu>-<compagnie>-<SE> ou même <cpu>-<compagnie>-<noyau>-<SE>. Exprimant cette manière, les noms de configurations de Linux/MIPS sont mips-inconnu-linux-gnu pour des cibles big endian pour mipsel-inconnu-linux-gnu pour des cibles little endian. Ces noms sont un peu long et peuvent être raccourcie en mips-linux ou misel-linux. Vous devez utiliser les même noms de configurations pour tous les paquetages qui comprend votre environnement de compilation croisé. Ainsi, bien que des noms comme mips-sni-linux ou misel-sni-linux sont de noms de configurations légales, utilisez plutôt mips-linux ou mipsel-linux; Ce sont des noms de configurations connu pour les autres paquetages comme les sources du noyau Linux et autrement ils devraient être changés pour la compilation croisé. Je référerais à ces noms de configurations cibles après avec <cible>.
Ceci est la première et la plus simple des parties - au moins aussi longtemps que vous essaierez d'installer le parfum d'UNIX après un mi-chemin plutôt sain. Entrez juste dans le dossier avec assez d'espace libre et suit les commandes suivantes :
gzip -cd binutils-<version>.tar.gz | tar xf - cd binutils-<version> patch -p1 < ../binutils-<version>-mips.patch ./configure --prefix=<prefix> --target=<target> make CFLAGS=-O2 make install
Ceci fonctionne habituellement très bien. Sur certaines machines l'utilisation de GCC 2.7.X comme compilateur est réputé pour déposer des core/ C'est un bug connu de GCC et peut être réparé en passant à la version 2.8.1 ou à egcs.
Des personnes possèdent un vieux en-tête de fichiers assert.h installé, probablement un reste de l'installation d'un vieux compilateur croisé. Ce fichier devrait causer aux scripts autoconf de planter silencieusement; il n'était jamais nécessaire et était uniquement installé à cause d'un bug dans un version très vieille de GCC. Vérifiez si le fichier <prefix>/<cible>/include/assert.h existe dans votre installation. S'il en est ainsi, effacez le simplement : il n'aurait jamais du être installé.
Maintenant la partie la moins rigolote commence : c'est le soi-disant problème de bootstrap. Dans note cas, cela veut dire que le processus d'installation d'egcs a besoin d'une glibc déjà installé, mais nous ne pouvons pas compiler glibc parce que nous n'avons pas encore de compilateurs croisés qui fonctionnent. Par chance, vous sauterez cette étape si c'est la première fois que vous installez un compilateur croisé. Plus tard, lorsque vous aurez déjà la glibc installée, les choses seront beaucoup plus calme. Donc maintenant, faites :
gzip -cd egcs-<version>.tar.gz | tar xf -
cd egcs-<version>
for i in egcs-1.0.2-libio.patch egcs-1.0.2-hjl.patch \
egcs-1.0.2-rth1.patch egcs-1.0.2-rth2.patch egcs-1.0.2-rth3.patch \
egcs-1.0.2-rth4.patch egcs-1.0.2-hjl2.patch egcs-1.0.2-jim.patch \
egcs-1.0.2-haifa.patch egcs-1.0.1-objcbackend.patch \
egcs-1.0.2-mips.patch; do patch -p1 -d < ../$i; done
./configure --prefix=<prefix> --with-newlib --target=<cible>
cd gcc
make LANGUAGES="c"
Notez que nous avons délibérément pas construit gcov, protoize, unprotoize et les librairies. Gcov n'a aucun sens dans l'environnement d'un compilateur croisé et protoize et unprotoize pourrait même effacer vos programmes natifs - c'est un bug dans les makefiles de gcc. Finalement, nous ne pouvons pas construire la librairies car nous n'avons pas encore installer glibc. Si tout a réussit, lancez l'installation avec :
make LANGUAGES="c" install
Un autre problème de bootstrap est que la construction de GCC a besoin de lancer des programmes sur la machines où GCC générera le code, mais lorsqu'un compilateur croisé fonctionne sur un type de machine différente, cela ne peut pas marcher. Lors de la construction de GCC, cela se passe pour le fichier d'en-tête float.h. Par chance, il y a une solution simple : télécharger le fichier d'en-tête d'un des serveurs ftp de Linux/MIPS ou prend le d'une des paquetages de binaires de Linux/MIPS natif. Plus tard, lors de la recompilation ou habituellement lors de la mise à jour d'egcs, le fichier float.h déjà installé sera déjà là puisque float.h change rarement. Installez le avec :
cp float.h <prefix>/<cible/<version>/include/float.h
où <version> est le numéro de version interne de la version d'egcs que vous utilisez. Pour egcs 1.0.2, par exemple, vous utiliserez egcs-2.90.27 pour <version>. Si ce n'est pas sur - ls est votre copain.
L'installation des sources du noyau est simple. Placez les juste dans les dossiers de votre choix et configurez les comme des fichiers qui seraient générés par la procédure qui les installerait. C'est du même type que d'habitude lors des configurations des sources du noyau pour une compilation native. Le seul problème est que vous devrez rencontrer dedans est que vous devrez avoir besoin d'installer des programmes GNU requie comme bash ou écrire par dessus la version des programmes fournis par le constructeur en plaçant la version GNU plutôt dans la variable PATH. Lors de la configuration, vous devrez répondre à la question "Utilisez vous un compilateur croisé ?" ("Are you using a crosscompiler?"), c'est l'option CONFIG_CROSSCOMPILER à "yes". Lorsque vous avez finis avec la configuration, tapez "make clean"; "make depend"; "make". La dernière commande make générera le fichier d'en-tête <linux/version.h> dont la compilation des programmes dépend. Ce fichier est généré dès le début de la commande make, donc si vous n'êtes pas intéressé actuellement dans la construction d'un noyau, vous devrez interrompre la compilation après que ce fichier ait été construit. Ça pourrait être une bonne idée, cependant, compilez quand même le noyau comme un test pour votre compilateur croisé nouvellement construit.
Si vous désirez uniquement le compilateur croisé pour la construction du noyau, c'est fait. La librairie libc du compilateur croisé est uniquement requis pour être capable de compiler les applications utilisateur.
Faire :
gzip -cd glibc-2.0.6.tar.gz | tar xf -
cd glibc-2.0.6
gzip -cd glibc-crypt-2.0.6.tar.gz | tar xf -
gzip -cd glibc-localedata-2.0.6.tar.gz | tar xf -
gzip -cd glibc-linuxthreads-2.0.6.tar.gz | tar xf -
patch -p1 <../glibc-2.0.6-mips.patch
mkdir build
cd build
CC=<target>-gcc BUILD_CC=gcc AR=<cible>-ar RANLIB=<ciblegt;-ranlib \
../configure --prefix=/usr --host=<cible> \
--enable-add-ons=crypt,linuxthreads,localedata --enable-profile
make
Vous avez maintenant une GNU libc compilée qui doit encore être installé. Ne tapez pas juste
make installCela écrirait par dessus vos fichiers systèmes à chaud avec des fichiers spécifiques Linux/MIPS ce qui aurait des effets désastreux. Au lieu de cela, installez GNU libc dans d'autre dossiers arbitraires <autredos> à partir du quel nous déplacerons les parties que nous avons besoin pour la compilation croisé dans le dossier cible actuel :
make install_root=<autredos> install
Maintenant cd dans <autredos> et finallement installez la GNU libc manuellement :
cd usr/include find . -print | cpio -pumd <prefix>/<cible>/include cd ../../lib find . -print | cpio -pumd <prefix>/<cible>/lib cd ../usr/lib find . -print | cpio -pumd <prefix>/<cible>/lib
La GNU Libc contiens aussi une vaste documentation online. Votre système devrait déjà avoir une version de cette documentation installé, donc si vous ne voulez pas installer les pages d'infos, qui vous sauveront un peu plus d'un megaoctet, ou si vous l'avez déjà installé, sautez à la prochaine étape :
cd ../info gzip -9 *.info* find . -name \*.info\* -print | cpio -pumd >prefix</info
Si vous ne booter votre installation, c'est maintenant finis.
La première tentative de construction de egcs sera stoppé par l'absence de la GNU libc. Maintenant que nous avons la libc installé, nous pouvons reconstruire egcs mais cette fois aussi complet que peut l'etre un compilateur croisé :
gzip -cd egcs-<version>.tar.gz | tar xf -
cd egcs-<version>
for i in egcs-1.0.2-libio.patch egcs-1.0.2-hjl.patch \
egcs-1.0.2-rth1.patch egcs-1.0.2-rth2.patch egcs-1.0.2-rth3.patch \
egcs-1.0.2-rth4.patch egcs-1.0.2-hjl2.patch egcs-1.0.2-jim.patch \
egcs-1.0.2-haifa.patch egcs-1.0.1-objcbackend.patch \
egcs-1.0.2-mips.patch; do patch -p1 <../$i; done
./configure --prefix=>prefix< --target=<cible>
make LANGUAGES="c c++ objective-c f77"
Comme vous pouvez le voir, la procédure est la meme que la première fois à l'exception que nous avons enlevez l'option --with-newlib. Cette option était nécessaire pour éviter l'arret de la construction de libgcc à cause de l'absence de libc. Maintenant installez avec :
make LANGUAGES="c c++ objective-c f77" install
Vous avez presque finis. Tout ce que vous devez faire maintenant est de réinstaller float.h qui a été éffacé par la dernière commande make install. Vous devrez faire cela chaque fois que vous réinstallerez egcs comme compilateur croisé. Si vous pensez ne pas avoir besoin des compilateur d'Objective C ou de F77, vous pouvez les ommetre à partir des commandes ci-dessus; chacune d'elles vous feront gagner environ 3 Mb. Ne construisez pas gcov, protoize ou unprotoize.
The answer to this question largely depends on your use of your crosscompiler environment. If you only intend to rebuild the Linux kernel then you have no need for the full blown setup and can safely omit the Objective C and F77 compilers. You must, however, build the C++ compiler, because building the libraries included with the egcs distribution requires C++.
La construction de GDB comme débugeur croisé est uniquement intéressant pour les développeurs du noyau; pour eux, GDB devrait leur simplifier la vie. Une telle initialisation de débogage alégé est consistitué toujours de deux parties : le débugeur alégé GDB fonctionne sur une machine et la machine cible fonctionne sous le noyau Linux/MIPS qui est débugué. Les machines sont typiquement interconnecté avec une ligne série. Le noyau de la machine cible a besoin d'etre équipé avec une "souche de débugeur" qui communique avec la machine hote GDB utilsant le protocole série alégé.
Dépendant de l'architecture cible, vous devriez implémenter la souche de débogeur vous meme. En général, vous devrez seuelemnt écrire des routines très simple pour la série. La tache est plutot simplifiée par le fait que la plupart des machines utilisent un matériel série similaire typiquement basé sur le 8250, 16450 ou des dérivés.