Gebäude Android aus Quellen: nicht unterstützte reloc 43

Question

Wenn ich Android kompilieren bin 5.1.1, bekomme ich Dutzende von Fehlern wie folgt aus:

... 
... 
... 
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 

und das Make-Prozess versagt schließlich:

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 

Ich habe versucht, Quellen mit und ohne Klang und mit verschiedenen Versionen von Klang zu bauen. Aber in neueren Zweigen ist der Klang eine Voraussetzung, und ohne ihn beginnt der Klang nicht.

Was könnte falsch sein?

Answer 1

Man sollte diesen Patch anwenden, um die Dinge arbeiten https://android-review.googlesource.com/#/c/223100/

öffnen build/core/clang/HOST_x86_common.mk Datei in Ihrem Android-Quellcode-Verzeichnis mit einigen Editor fügen Sie diese Zeilen zu erhalten, wie in diesem

link erwähnt

Für Android Lollipop oder einer früheren Version, achten Sie darauf, -no-integrated-as während der Anwendung dieses Patches zu halten. Stellen Sie sicher, dass die Zeilenfortsetzungen korrekt sind (\ am Ende jeder Zeile mit Ausnahme der letzten Zeile).

Aber -no-integrated-as wird in Marshmallow entfernt.

Answer 2

Bauen Sie auf Arch Linux? Ich habe das gleiche Problem seit heute. Meine vorherigen Builds waren vor 3 Tagen und alles war in Ordnung. Heute scheitern alle.

Ich sehe das Admin einige Pakete aktualisiert vor 2 Tagen, vor allem diese

[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 der Täter sein könnte? (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=808206)

auch https://groups.google.com/d/msg/android-x86/U1XpL0tUpqw/y4W3wRCdJgAJ sehen ...

Answer 3

Als harte Abhilfe, die ich nur vorkompilierte Linker mit Soft-Link auf /usr/bin/ld.gold ersetzt. Es wurde hier beschrieben: https://bbs.archlinux.org/viewtopic.php?id=209698.

Answer 4

Es mir funktioniert:
in Datei /art/build/Android.common_build.mk erfahren Sie:

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

Änderung:

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

Wenn es immer noch nicht funktioniert, versuchen Sie dies in Ihrem Android-Root-Pfad: cp /usr/bin/ld.gold prebuilts/gcc/linux-x86/host/x86_64-linux-glibc2.11-4.6/x86_64-linux/bin/ld

Answer 5

Probleme kommt von einer inkompatiblen Änderung in binutils: einige sectio n wurden hinzugefügt. Einige Build-Plattform haben die neuen binutils und Android Build-Baum haben alte. Der Fehler kommt von der Definition der Aufrufvariablen. Diese sagen nicht, dass clang die bereitgestellte Build-Kette verwenden soll. Dann verwendet clang die native Build-Plattform binutils (hier/usr/bin/als stattdessen die Prebuiltts als). Dann impliziert das Fixieren das Patch, auf das mysticTot zeigt, und dann das Entfernen aller von der Toolchain erzeugten Binaries (je nachdem, wo der Fehler auftaucht, könnte sich dies ändern, aber das Entfernen aller STATIC_LIBRARIES/SHARED_LIBRARIES/EXECUTABLES usw. outs in out tree sollte es tun). Entfernen Sie auch den Cache-Cache (da er .o speichert) und erstellen Sie ihn anschließend neu. Die von Ov3r1oad bereitgestellte Korrektur, die darin besteht, die vorgefertigte Toolchain ld durch die native ld zu ersetzen, ist keine Lösung, sondern nur ein Workaround und könnte gefährlich sein (die Mischbereichsnummer ist nicht gut). Hoffe, es wird helfen.