Compilare un'applicazione 32 su 64 bit, senza eliminare GNU EABI per ARM

4

Voglio creare un programma C ++ per 32 bit sul mio 64 bit 16.04.

/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

Il collegamento usando g ++ non riesce a cercare -lstdc ++ dice che dovrei installa libc6-i386 libc6-dev-i386 lib32gcc1 lib32stdc++6 , che restituisce:

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, bene, proviamo ora la risposta accettata: installa g++-multilib (o gcc-multilib , il risultato è lo stesso):

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.

Mi piace essere in grado di costruire GNU C11 sul mio portatile e farlo girare sul mio telefono ( vedere qui ), che è possibile con arm-linux-gnueabi-gcc , quindi non voglio liberarmene. (Non sono interessato a fare lo stesso per C ++ 11).

I nuovi pacchetti che gcc-multilib installerà sembrano essere solo C ++, ma rimuoveranno i compilatori C e binutils per ARM e altre piattaforme, che voglio mantenere.

Posso avere simultaneamente compilatori per GNU C ++ 11 a 32 bit e ARM GNU C11?

    
posta cat 14.06.2016 - 16:29

1 risposta

1

L'installazione del pacchetto di altri compilatori di architettura li mette in un'area di sistema. Gli eseguibili hanno un nome univoco, ma il pacchetto è troppo "utile" e pensa che tu abbia davvero bisogno di un link per un nome breve (come gcc) per indicarli, e whoa, un altro pacchetto usa già quel link, devi cancellarlo per te. Questo potrebbe andare bene in una macchina virtuale, dedicata a un tipo di toolchain, ma non è auspicabile in circostanze normali.

Puoi decomprimere il pacchetto tu stesso e copiare gli eseguibili in / usr / bin se lo desideri. Se più utenti stanno usando il compilatore, sarebbe un modo per farlo, ma come singolo utente, non mi sono mai preoccupato. Ho appena scompattato localmente nella mia directory e ho impostato le variabili di ambiente e i collegamenti locali secondo necessità. Lo svantaggio non sta ricevendo gli aggiornamenti del pacchetto man mano che escono. Il vantaggio è selezionare quando si desidera modificare la versione del compilatore, testare la nuova installazione contro il vecchio, e quando hai convalidato il nuovo pacchetto soddisfa le tue esigenze, puoi passare. Non puoi farlo mettendo la nuova versione nell'area di sistema standard perché i nomi delle nuove versioni non sono diversi da quelli precedenti.

esempio di uno script di installazione di toolchain 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

Gli eseguibili sono in $ {COMPILER_PATH} con nomi come
 arm-none-linux-gnueabi-gcc in modo da poter aggiungere un collegamento a quella directory con il nome breve:

ln -s arm-none-linux-gnueabi-gcc gcc

Per tua comodità, la maggior parte dei makefile esegue le definizioni come quelle mostrate sopra, e il nome completo potrebbe essere stato utilizzato con facilità al posto di un nome breve.

Avere uno script di installazione per ogni architettura e si può avere uno script di installazione per diverse versioni di un compilatore all'interno di un'architettura.

    
risposta data ubfan1 15.06.2016 - 02:21

Leggi altre domande sui tag