2012-09-20 13 views
7

Provo a compilare un codice C per un sistema Linux embedded (personalizzato) basato su ARM. Ho creato una macchina virtuale Ubuntu con un cross-compilatore chiamato arm-linux-gnueabi-gcc-4.4 perché sembrava quello di cui avevo bisogno. Ora, quando ho compilare il mio codice con questo gcc, produce un binario come questo:Compilatura incrociata per un sistema Linux basato su ARM incorporato

$ 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 

Quando provo a fare funzionare questo binario su Linux embedded, ottengo

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

permessi sono sufficienti. Posso solo immaginare che qualcosa non va con il formato binario, così ho guardato un po 'di binario a lavorare come riferimento:

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

vedo che ci sono alcune differenze, ma non ho le conoscenze per ricavare che cosa esattamente mi serve risolvere e come posso risolvere il problema. Qualcuno può spiegare quale differenza è critica?

Un'altra cosa che ho guardato sono le dipendenze:

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

(È interessante notare che questo funziona sul sistema di destinazione anche se non può eseguire il binario.) Il sistema embedded ha solo libc.so.0 disponibili. Suppongo di dover dire al compilatore la versione di libc a cui voglio collegarmi, ma a quanto ho capito, gcc solo link con la versione che viene fornita, è corretto? Cosa posso fare a riguardo?

Edit: Ecco il Makefile che uso:

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 
+0

Se hai poca memoria, il più piccolo 'uClibc' può sostituire' glibc'. Comunque avresti bisogno di un compilatore * gcc * costruito per usare 'uClibc'. Un metodo (relativamente) facile per ottenere una toolchain funzionante di * gcc *, * uClibc * (o * glibc *) e amici più la compilazione del kernel Linux, Busybox e altri pacchetti tutto da sorgente è usare 'BuildRoot'. Con una buona combinazione di compilatore + libc, puoi collegare la tua app in modo statico ed essere indipendente dalle librerie del bersaglio. – sawdust

risposta

4

Ciò che probabilmente si dovrebbe fare è quello di installare libc6 sul sistema embedded. Leggi this thread su un problema simile. La soluzione in post # 5 era quello di installare:

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 

L'altra opzione è quella di ottenere il libc dal sistema embedded sul vostro VM e poi passarlo al gcc linker e utilizzare l'opzione -static.

Questa soluzione è stata menzionata anche nel thread precedente. Maggiori informazioni sul collegamento statico here.

Altre cose da provare:

In this thread suggeriscono di rimuovere la bandiera -mabi=apcs-gnu dal makefile se si sta utilizzando uno.

This article suggerisce feedint gcc il flag -nostdlib se si sta compilando dalla riga di comando.

Oppure è possibile passare all'utilizzo del compilatore arm-none-eabi-gcc. Riferimenti su questo possono essere trovati here e here.

+0

Non riesco a installare il software sul sistema incorporato, ma il collegamento alla libc del sistema ha generato questo errore: 'ld: errore: oggetto di origine ../libc.so.0 ha la versione EABI 0, ma la destinazione principale ha EABI versione 5'. I risultati di google per questo errore implicano che ho effettivamente bisogno di un altro gcc, è corretto? – flyx

+0

@flyx Stai usando un makefile o stai usando gcc direttamente sulla riga di comando? –

+0

@flyx Vedere la modifica per altre cose che potrebbero essere utili –

Problemi correlati