2016-03-16 64 views
25

Quando sto compilando Android 5.1.1, ricevo decine di errori come questo:Costruzione Android da fonti: reloc non supportato 43

... 
... 
... 
libnativehelper/JniInvocation.cpp:165: error: unsupported reloc 43 
libnativehelper/JniInvocation.cpp:165: error: unsupported reloc 43 
libnativehelper/JniInvocation.cpp:165: error: unsupported reloc 43 
libnativehelper/JniInvocation.cpp:165: error: unsupported reloc 43 

e il processo di fare finalmente viene a mancare:

clang: error: linker command failed with exit code 1 (use -v to see invocation) 
build/core/host_shared_library_internal.mk:44: recipe for target 'out/host/linux-x86/obj32/lib/libnativehelper.so' failed 
make: *** [out/host/linux-x86/obj32/lib/libnativehelper.so] Error 1 

Ho provato a creare sorgenti con e senza clang e con diverse versioni di clang. Ma su rami più nuovi, clang è un requisito e make non parte senza di esso.

Cosa potrebbe essere che non va?

risposta

20

Si dovrebbe applicare questa patch per ottenere le cose di lavoro di file https://android-review.googlesource.com/#/c/223100/

aperto build/core/clang/HOST_x86_common.mk nella directory di codice sorgente di Android con alcuni editor di aggiungere queste righe, come accennato in questo link

Per Android Lollipop o qualsiasi precedente versione, assicurarsi di mantenere -no-integrated-as mentre si applica questa patch. Assicurarsi che le continuazioni di linea siano corrette (\ alla fine di ogni riga eccetto l'ultima riga).

Ma, -no-integrated-as viene rimosso in Marshmallow.

+0

grazie per il collegamento alla patch, ho usato git cherry-pick e sembra che funzioni OK (la build è ancora in corso ed era solo uno dei difetti che ho dovuto risolvere ... in attesa del prossimo ...) – Mixaz

+0

Ha funzionato per me in quel momento. – mysticTot

+0

funziona davvero, grazie – Mixaz

2

Stai costruendo su Arch Linux? Ho lo stesso problema da oggi. Le mie precedenti build erano 3 giorni fa e andavano tutto bene. Oggi falliscono tutti.

vedo l'amministratore aggiornato alcuni pacchetti 2 giorni fa, in particolare questi

[2016-03-16 15:29] [ALPM] upgraded glibc (2.22-3 -> 2.23-1) 
[2016-03-16 15:29] [ALPM] upgraded lib32-glibc (2.22-3.1 -> 2.23-1) 
[2016-03-16 15:29] [ALPM] upgraded lib32-gcc-libs (5.3.0-3 -> 5.3.0-5) 
[2016-03-16 15:29] [ALPM] upgraded gcc-libs-multilib (5.3.0-3 -> 5.3.0-5) 
[2016-03-16 15:29] [ALPM] upgraded libcap (2.24-2 -> 2.25-1) 
[2016-03-16 15:29] [ALPM] upgraded binutils (2.25.1-3 -> 2.26-3) 
[2016-03-16 15:29] [ALPM] upgraded gcc-multilib (5.3.0-3 -> 5.3.0-5) 
[2016-03-16 15:29] [ALPM] upgraded libcups (2.1.2-3 -> 2.1.3-1) 

binutils potrebbe essere il colpevole? (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=808206)

vedere anche https://groups.google.com/d/msg/android-x86/U1XpL0tUpqw/y4W3wRCdJgAJ ...

+0

Quindi l'hai aggiustato in qualche modo? Recentemente ho lo stesso problema con Lollipop su Arch. – Ov3r1oad

+0

Sono incappato anche su questo bug report debian: * Questo accadrebbe con gcc-5 e con gcc-4.9. Il downgrade di libc6 lo risolverebbe. Dopo alcuni tentativi mi sono reso conto che l'aggiornamento a binutils = 2.25.90.20151209-1 (attualmente più recente in sid) lo risolve. Cioè con l'ultimo libc6 e gli ultimi pacchetti binutils funzionano. * Il mio sistema di compilazione è un contenitore di Ubuntu 16.10 su un host di arch linux e non sta utilizzando una delle versioni interessate. Ma il sistema di build Android sta scegliendo il suo linker dalla sua directory predefinita (gcc 4.6, glibc 2.11). ** Quindi: come possiamo usare gli strumenti di compilazione a livello di sistema con Android? ** –

+0

Come ho capito l'idea, l'uso della finestra mobile può aiutare con l'impostazione dell'ambiente di costruzione: https://github.com/justfortherec/fairphone2-build- Tuttavia non l'ho usato io stesso, ma probabilmente proverò a provarlo a causa di un numero infinito di errori nella creazione di FP2 Android dalla sorgente, che avrebbe dovuto essere un processo impeccabile. Ma non sono sorpreso visto che ho già avuto problemi come quello di creare CM su Arch Linux, poi ho capito che la prossima volta costruirò un ambiente consigliato (Ubuntu), ma sembra non essere abbastanza. Quindi il ** docker ** è il nostro futuro? ;) – Mixaz

3

Come una soluzione difficile Ho appena sostituito linker precompilati con soft link sul /usr/bin/ld.gold. Qui descritto: https://bbs.archlinux.org/viewtopic.php?id=209698.

+0

Funziona per me, grazie! (Sto costruendo cm12.1, Lollipop, su Arch Linux) –

+1

non funziona su di me: ubuntu 16.04, compila android 5.1.1_r6. – Ezio

21

Si lavora per me:
nel file di /art/build/Android.common_build.mk, scoprire:

# Host. 
ART_HOST_CLANG := false 
ifneq ($(WITHOUT_HOST_CLANG),true) 
    # By default, host builds use clang for better warnings. 
    ART_HOST_CLANG := true 
endif 

modifica:

# Host. 
ART_HOST_CLANG := false 
ifeq ($(WITHOUT_HOST_CLANG),false) 
    # By default, host builds use clang for better warnings. 
    ART_HOST_CLANG := true 
endif 

Se non funziona ancora, prova questo nel tuo percorso root Android: cp /usr/bin/ld.gold prebuilts/gcc/linux-x86/host/x86_64-linux-glibc2.11-4.6/x86_64-linux/bin/ld

+6

"cp ld.gold" funziona per me. Molte grazie. –

+0

Il cambio makefile è d'oro! grande scoperta –

+0

FWIW, ho avuto lo stesso errore durante la creazione di libcxx e libcxxabi. La copia non funziona per me (ho ".../ld non trovato (forse ld non è installato), ma il soft-linking (non so perché). – autra

4

I problemi provengono da un cambiamento incompatibile in binutils: alcuni secondi n sono stati aggiunti. Alcune piattaforme di sviluppo hanno i nuovi binutils e l'albero di build Android hanno uno vecchio. Il bug proviene dalla definizione di variabili di invocazione clang. Questi non dicono a clang di usare la catena di build fornita. Quindi clang usa i binutils della piattaforma di costruzione nativa (qui/usr/bin/come invece i prebuilt forniti come). Quindi la correzione implica l'applicazione della patch puntata da mysticTot e quindi la rimozione di tutti i binari prodotti dalla toolchain (in base a dove l'errore appare potrebbe cambiare, ma la rimozione di tutte le directory di STATIC_LIBRARIES/SHARED_LIBRARIES/EXECUTABLES ecc. Dovrebbe farlo). Rimuove anche la cache di ccache (man mano che memorizza .o) quindi ricompila. La correzione fornita da Ov3r1oad consistente nel sostituire la toolchain ld preimpostata dal ld nativo non è una soluzione, solo una soluzione e potrebbe essere pericolosa (il numero della sezione di mixaggio non è buono). Spero che possa aiutarti.

Problemi correlati