Compilar um aplicativo 32 em 64 bits, sem se livrar do GNU EABI for ARM

4

Eu quero construir um programa em C ++ para 32 bits no meu 16 bits de 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

Vincular usando g + + falha ao pesquisar por -lstdc ++ diz que eu deveria instala libc6-i386 libc6-dev-i386 lib32gcc1 lib32stdc++6 , o que dá:

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, bom, agora vamos tentar a resposta aceita: instalar g++-multilib (ou gcc-multilib , o resultado é o mesmo):

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.

Eu gosto de poder criar o GNU C11 no meu laptop e executá-lo no meu telefone ( veja aqui ), o que é possível com arm-linux-gnueabi-gcc , então eu não quero me livrar disso. (Estou desinteressado em fazer o mesmo para o C ++ 11).

Os novos pacotes que gcc-multilib instalará parecem ser apenas C ++, mas removerão os compiladores C e binutils para o ARM e outras plataformas, o que eu quero manter.

Posso ter compiladores para o GNU C ++ 11 de 32 bits e o ARM GNU C11 simultaneamente?

    
por cat 14.06.2016 / 16:29

1 resposta

1

A instalação de pacotes de outros compiladores de arquitetura os coloca em uma área do sistema. Os executáveis são nomeados exclusivamente, mas o pacote é muito "útil" e acha que você realmente precisa de um link de nome curto (como o gcc) para apontar para eles, e whoa, outro pacote já usa esse link, precisa excluí-lo para você. Isso pode ser bom em uma máquina virtual, dedicada a um tipo de toolchain, mas não é desejável em circunstâncias normais.

Você pode descompactar o pacote e copiar os executáveis em / usr / bin, se desejar. Se vários usuários estão usando o compilador, seria uma maneira de fazê-lo, mas como um único usuário, eu nunca me incomodei. Acabei de descompactar localmente no meu próprio diretório e definir variáveis de ambiente e links locais, conforme necessário. A desvantagem não é obter atualizações de pacotes quando elas são lançadas. O benefício é selecionar quando você quer mudar a versão do compilador, testar a nova instalação contra o antigo, e quando você tiver validado o novo pacote atende às suas necessidades, você pode alternar. Você não pode fazer isso colocando a nova versão na área padrão do sistema porque os nomes das novas versões não são diferentes dos antigos.

exemplo de um script de configuração de conjunto de ferramentas local:

$ 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

Os executáveis estão em $ {COMPILER_PATH} com nomes como:  arm-none-linux-gnueabi-gcc, assim você pode adicionar um link para o diretório com o nome curto:

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

Apenas uma conveniência para você, a maioria dos makefiles executa as definições como as mostradas acima, e o nome completo poderia ser usado com facilidade em vez de um nome curto.

Tenha um script de configuração para cada arquitetura e você pode ter scripts de configuração para diferentes versões de um compilador dentro de uma arquitetura.

    
por ubfan1 15.06.2016 / 02:21