Compiler une application 32 sur 64 bits, sans se débarrasser de GNU EABI pour ARM
Je veux construire un programme C++ pour 32 bits sur mon 16.04 64 bits.
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/5/libstdc++.so when searching for -lstdc++
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/5/libstdc++.a when searching for -lstdc++
/usr/bin/ld: cannot find -lstdc++
collect2: error: ld returned 1 exit status
La liaison avec g ++ échoue lors de la recherche de -lstdc ++ dit que je devrais installer libc6-i386 libc6-dev-i386 lib32gcc1 lib32stdc++6 , ce qui donne:
Reading package lists... Done
Building dependency tree
Reading state information... Done
lib32gcc1 is already the newest version (1:6.0.1-0ubuntu1).
lib32gcc1 set to manually installed.
libc6-dev-i386 is already the newest version (2.23-0ubuntu3).
libc6-dev-i386 set to manually installed.
libc6-i386 is already the newest version (2.23-0ubuntu3).
lib32stdc++6 is already the newest version (5.3.1-14ubuntu2.1).
0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded.
OK, bien, essayons maintenant la réponse acceptée: install g++-multilib (ou gcc-multilib, le résultat est le même):
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages were automatically installed and are no longer required:
binutils-arm-linux-gnueabi cpp-5-arm-linux-gnueabi cpp-arm-linux-gnueabi gcc-5-arm-linux-gnueabi-base
gcc-5-cross-base libasan2-armel-cross libasan2-dbg-armel-cross libatomic1-armel-cross libatomic1-dbg-armel-cross
libc6-armel-cross libc6-armhf-armel-cross libc6-armhf-cross libc6-dev-armel-cross libc6-dev-armhf-armel-cross
libc6-dev-armhf-cross libgcc-5-dev-armel-cross libgcc1-armel-cross libgcc1-dbg-armel-cross libgomp1-armel-cross
libgomp1-dbg-armel-cross libhfasan2-armel-cross libhfatomic1-armel-cross libhfgcc-5-dev-armel-cross
libhfgcc1-armel-cross libhfgomp1-armel-cross libhfstdc++6-armel-cross libhfubsan0-armel-cross libstdc++6-armel-cross
libubsan0-armel-cross libubsan0-dbg-armel-cross linux-libc-dev-armel-cross linux-libc-dev-armhf-cross
Use 'Sudo apt autoremove' to remove them.
The following additional packages will be installed:
g++-5-multilib gcc-multilib lib32gcc1-dbg lib32stdc++-5-dev lib32stdc++6-5-dbg libx32gcc1-dbg libx32stdc++-5-dev
libx32stdc++6-5-dbg
The following packages will be REMOVED:
gcc-5-arm-linux-gnueabi gcc-5-multilib-arm-linux-gnueabi gcc-arm-linux-gnueabi
The following NEW packages will be installed:
g++-5-multilib g++-multilib gcc-multilib lib32gcc1-dbg lib32stdc++-5-dev lib32stdc++6-5-dbg libx32gcc1-dbg
libx32stdc++-5-dev libx32stdc++6-5-dbg
0 upgraded, 9 newly installed, 3 to remove and 1 not upgraded.
Need to get 14.7 MB of archives.
After this operation, 82.5 MB of additional disk space will be used.
J'aime pouvoir construire GNU C11 sur mon ordinateur portable et le faire fonctionner sur mon téléphone ( voir ici ), ce qui est possible avec arm-linux-gnueabi-gcc, donc je ne veux pas se débarrasser de ça. (Je ne suis pas intéressé à faire de même pour C++ 11).
Les nouveaux packages que gcc-multilib installera semblent être uniquement en C++, mais ils supprimeront les compilateurs C et binutils pour ARM et d’autres plates-formes, que je souhaite conserver.
Puis-je avoir des compilateurs pour GNU C++ 11 et ARM GNU C11 32 bits simultanément?
L'installation de paquetages d'autres compilateurs d'architecture les place dans une zone système. Les exécutables portent des noms uniques, mais le paquet est trop "utile" et pense que vous avez vraiment besoin d'un lien de nom court (comme gcc) pour les pointer, et qui, un autre paquet utilise déjà ce lien, il faut le supprimer pour vous. Cela peut convenir à une machine virtuelle dédiée à un type d’outil, mais n’est pas souhaitable dans des circonstances normales.
Vous pouvez décompresser le paquet vous-même et copier les fichiers exécutables dans/usr/bin si vous le souhaitez. Si plusieurs utilisateurs utilisent le compilateur, ce serait une façon de le faire, mais en tant qu'utilisateur unique, je ne me suis jamais ennuyé. Je viens de décompresser localement dans mon propre répertoire et de définir les variables d’environnement et les liens locaux en fonction des besoins. L'inconvénient est de ne pas obtenir les mises à jour des paquets dès leur publication. L’avantage est de choisir quand vous voulez changer la version du compilateur, tester la nouvelle installation par rapport à l’ancienne, et lorsque vous avez validé le nouveau paquet qui répond à vos besoins, vous pouvez basculer. Vous ne pouvez pas faire cela en plaçant la nouvelle version dans la zone système standard, car les noms de nouvelle version ne diffèrent pas des anciens.
exemple de script de configuration d'une chaîne d'outils locale:
$ cat crossexp
MY_ARM_BASE=${HOME}/dev/toolchain/arm-2008q3
C_INCLUDE_PATH=${MY_ARM_BASE}/lib/gcc/arm-none-linux-gnueabi/4.3.2/include:${MY_ARM_BASE}/lib/gcc/arm-none-linux-gnueabi/4.3.2/include-fixed
LIBRARY_PATH=${MY_ARM_BASE}/arm-none-linux-gnueabi/libc/lib:${MY_ARM_BASE}/arm-none-linux-gnueabi/libc/usr/lib
CPLUS_INCLUDE_PATH=${MY_ARM_BASE}/arm-none-linux-gnueabi/include/c++/4.3.2
#OBJC_INCLUDE_PATH
COMPILER_PATH=${MY_ARM_BASE}/bin
#LD_RUN_PATH
#GPROF_PATH
#######
CC=${COMPILER_PATH}/gcc
CXX=${COMPILER_PATH}/g++
RANLIB=${COMPILER_PATH}/ranlib
STRIP=${COMPILER_PATH}/strip
export C_INCLUDE_PATH LIBRARY_PATH CPLUS_INCLUDE_PATH OMPILER_PATH
export CC CXX RANLIB STRIP
Les exécutables sont dans $ {COMPILER_PATH} avec des noms comme
arm-none-linux-gnueabi-gcc afin que vous puissiez ajouter un lien vers ce répertoire avec le nom abrégé:
ln -s arm-none-linux-gnueabi-gcc gcc
Pour votre commodité, la plupart des makefiles utilisent les définitions ci-dessus, et le nom complet aurait tout aussi bien pu être utilisé là-bas au lieu d'un nom court.
Ayez un script d'installation pour chaque architecture et vous pouvez avoir des scripts d'installation pour différentes versions d'un compilateur au sein d'une architecture.