compilação cruzada para ARM: erro nenhum tal arquivo ou diretório

2

Eu escrevi um programa Hello world simples e o compilei com o compilador gcc-arm-linux-gnueabi . Ele compila bem, mas quando eu tento executá-lo na máquina ARM ele reclama "nenhum tal arquivo ou diretório". Eu acho que gcc-arm-linux-gnueabi é para Linux embarcado apenas devido a e(mbedded)abi . É diferente do ARM Linux ABI?

Por favor, ajude-me a resolver este problema

o código está aqui

#include "stdio.h"

int main(void) {
  printf("Hello world !\n");
  return 0;
}

compilado como

> arm-linux-gnueabi-gcc -Wall -o crosscomp hello.c

Quando executo este crosscomp no erro de máquina ARM de destino é crosscomp sem tal arquivo ou dir

EDITAR Quando eu estava usando arm-linux-gnueabi-gcc , o ponto de entrada não estava correspondendo ao ponto de entrada da máquina de destino (readelf -l crosscom), mas quando eu compilei com aarch64-linux-gnu-gcc do ponto de entrada correspondido à máquina de destino. Mas agora o erro se torna permissão negada em ./crosscomp. Eu tentei com sudo que diz crosscomp: nenhum tal comando.

    
por shami 14.04.2017 / 13:52

1 resposta

0

Como identificar o problema?

file cross_compiled_executable

Contém algo como:

interpreter /lib/ld-uClibc.so.0

e o problema é que esse arquivo não existe no destino.

Como resolver o problema?

Use um compilador adequado:

  • a pessoa que criou a imagem de disco deve fornecer-lhe o compilador cruzado ou informá-lo exatamente como criá-lo, por exemplo, com crosstool-ng .
  • compile sua própria imagem e compilação cruzada, por exemplo com Buildroot . Aqui está um exemplo .
  • use um compilador nativo no destino. Mas geralmente os alvos são muito mais lentos que o seu host e o espaço é restrito, então você provavelmente não quer fazer isso.

    Você também pode usar um emulador funcional, como o QEMU, para criar, e só executar os programas em uma plataforma mais lenta, por exemplo, gem5 ou uma prancha lenta.

Apenas hackear o interpreter é potencialmente insuficiente, especialmente você precisa garantir compatibilidade binária entre o programa e o alvo libc, ou interfaces de programa e kernel (syscalls, /proc , etc.) se você tentar usar -static (o kernel de destino pode ser muito antigo e não conter as interfaces necessárias). A única solução robusta é usar o toolchain correto.