Cross-Compilation pour l'embarqué ARM-Linux basée sur le système de

J'essaie de compiler du code C pour l'embarqué (personnalisé) ARM-Linux basée sur le système. - Je configurer une machine virtuelle Ubuntu avec un cross-compilateur nommé arm-linux-gnueabi-gcc-4.4 parce qu'il semblait que j'avais besoin. Maintenant, quand je compile mon code avec cette gcc, il produit un binaire comme ceci:

$ file test1
test1: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked
(uses shared libs), for GNU/Linux 2.6.31,
BuildID[sha1]=0x51b8d560584735be87adbfb60008d33b11fe5f07, not stripped

Lorsque j'essaie d'exécuter ce fichier binaire sur le Linux embarqué, - je obtenir

$ ./test1
-sh: ./test1: not found

Autorisations sont suffisantes. Je peux seulement imaginer que quelque chose de mal avec le format binaire, donc j'ai regardé quelques binaire travail comme référence:

$ file referenceBinary
referenceBinary: ELF 32-bit LSB executable, ARM, version 1, dynamically linked
(uses shared libs), stripped

Je vois qu'il y a quelques différences, mais je n'ai pas les connaissances nécessaires pour tirer exactement ce que j'ai besoin de fixer et comment je peux résoudre ce problème. Quelqu'un peut m'expliquer quelle différence est critique?

Une autre chose que j'ai regardé sont les dépendances:

$ ldd test1
    libc.so.6 => not found (0x00000000)
    /lib/ld-linux.so.3 => /lib/ld-linux.so.3 (0x00000000)

(En fait, cela fonctionne sur le système cible, bien qu'il ne peut pas exécuter le binaire.) Le système embarqué n'a qu'un libc.so.0 disponibles. Je suppose que j'ai besoin de dire au compilateur de la version de la libc je veux le lien "contre", mais comme je le comprends, gcc juste des liens par rapport à la version il est livré avec, est-ce correct? Que puis-je faire à ce sujet?

Edit: Voici le Makefile que j'utilise:

CC=/usr/bin/arm-linux-gnueabi-gcc-4.4
STRIP=/usr/bin/arm-linux-gnueabi-strip          
CFLAGS=-I/usr/arm-linux-gnueabi/include             
LDFLAGS=-nostdlib
LDLIBS=../libc.so.0

SRCS=test1.c
OBJS=$(subst .c,.o,$(SRCS))

all: test1

test1: $(OBJS)
    $(CC) $(LDFLAGS) -o main $(OBJS) $(LDLIBS)
    $(STRIP) main

depend: .depend

.depend: $(SRCS)
    rm -f ./.depend
    $(CC) $(CFLAGS) -MM $^>>./.depend;

clean:
    rm -f $(OBJS)

include .depend
Si vous êtes serré sur la mémoire, de la plus petite uClibc peut se substituer à glibc. Cependant, vous auriez besoin d'un gcc compilateur construit à utiliser uClibc. Un (relativement) facile de se procurer un travail de la chaîne de gcc, uClibc (ou glibc) et les amis plus la construction du noyau Linux, Busybox, et d'autres paquets de la source est d'utiliser BuildRoot. Avec un bon compilateur + libc combinaison, vous pouvez lier votre application de manière statique, et être indépendant de la cible des bibliothèques.

OriginalL'auteur flyx | 2012-09-20

  1. 4

    Ce que vous devriez faire est d'installer libc6 sur le système embarqué. Lire ce fil sur un problème similaire. La solution dans le post #5 a été à installer:

    libc6_2.3.6.ds1-13etch9_arm.deb
linux-kernel-headers_2.6.18-7_arm.deb
libc6-dev_2.3.6.ds1-13etch9_arm.deb

    Votre autre option est d'obtenir le libc du système embarqué sur votre VM et puis la passer à la gcc de l'éditeur de liens et d'utiliser le -static option.

    Cette solution a également été mentionné dans le fil au-dessus. Lire plus à propos de la liaison statique ici.

    Autres choses à essayer:

    Dans ce fil ils proposer la suppression de la -mabi=apcs-gnu drapeau de votre makefile si vous en utilisez un.

    Cet article suggère feedint de gcc le -nostdlib drapeau si vous êtes à la compilation à partir de la ligne de commande.

    Ou vous pourriez passer à l'utilisation de la arm-none-eabi-gcc compilateur. Les références sur ce qui peut être trouvé ici et ici.

    Je ne peux pas installer de logiciel sur le système embarqué, mais faire des liens vers le système de la libc mis cette erreur: ld: error: Source object ../libc.so.0 has EABI version 0, but target main has EABI version 5. Les résultats de google pour cette erreur implique que j'ai vraiment besoin d'un autre gcc, est-ce correct?
    Êtes-vous à l'aide d'un makefile ou vous utilisez gcc directement sur la ligne de commande?
    Voir modifier pour d'autres choses à essayer que pourrait être utile
    arm-none-eabi-gcc est probablement le bon choix. Je n'ai pas essayer car j'ai eu un travail de la chaîne auprès du fabricant de matériel, mais je vais marquer ce que la réponse est correcte, de toute façon. Les liens ont été très utiles.

    OriginalL'auteur embedded.kyle