ONNX Runtime für Inferencing erstellen
Folgen Sie den untenstehenden Anweisungen, um ONNX Runtime für Inferencing zu erstellen.
Inhalt
- CPU
- Unterstützte Architekturen und Build-Umgebungen
- Allgemeine Build-Anweisungen
- Weitere Build-Optionen
CPU
Einfacher CPU-Build
Voraussetzungen
-
Source-Baum auschecken
git clone --recursive https://github.com/Microsoft/onnxruntime.git cd onnxruntime -
Installieren Sie Python 3.10+.
-
Installieren Sie cmake-3.28 oder höher.
Unter Windows empfehlen wir, die neueste Version von WinGet zu beziehen. Bitte führen Sie aus:
winget install -e --id Kitware.CMakeUnter Linux können Sie es von pypi beziehen. Bitte führen Sie aus:
python3 -m pip install cmake which cmakeWenn die obigen Befehle fehlschlugen, holen Sie sich CMake bitte manuell von https://cmake.org/download/.
Nach der Installation können Sie Folgendes ausführen:
cmake --version, um zu überprüfen, ob die Installation erfolgreich war.
Bauanleitungen
Windows
Öffnen Sie die Developer Command Prompt für die Visual Studio-Version, die Sie verwenden möchten. Dies richtet die Umgebung korrekt ein, einschließlich der Pfade zu Ihrem Compiler, Linker, Dienstprogrammen und Header-Dateien.
.\build.bat --config RelWithDebInfo --build_shared_lib --parallel --compile_no_warning_as_error --skip_submodule_sync
Der Standard-Windows-CMake-Generator ist Visual Studio 2022. Andere Visual Studio-Versionen werden nicht unterstützt.
Wenn Sie ein ARM64-Binary auf einer Windows ARM64-Maschine erstellen möchten, können Sie denselben Befehl wie oben verwenden. Stellen Sie einfach sicher, dass Ihr Visual Studio, CMake und Python alle ARM64-Versionen sind.
Wenn Sie ein ARM64- oder ARM64EC-Binary auf einer Windows x86-Maschine cross-kompilieren möchten, müssen Sie "–arm64" oder "–arm64ec" zum obigen Build-Befehl hinzufügen.
Bitte stellen Sie sicher, dass Ihr Python-Interpreter eine 64-Bit-Windows-Anwendung ist. Wir unterstützen 32-Bit-Builds nicht mehr.
Linux
./build.sh --config RelWithDebInfo --build_shared_lib --parallel --compile_no_warning_as_error --skip_submodule_sync
macOS
Standardmäßig ist ONNX Runtime für eine minimale Ziel-macOS-Version von 13.3 konfiguriert. Die freigegebene Bibliothek in den Nuget(s) und das Python-Wheel können auf macOS-Versionen von 13.3+ installiert werden.
Wenn Sie Xcode verwenden möchten, um onnxruntime für x86_64 macOS zu erstellen, fügen Sie das Argument --use_xcode zur Befehlszeile hinzu.
Ohne dieses Flag wird der CMake-Build-Generator standardmäßig Unix makefile sein.
Heutzutage sind Mac-Computer entweder Intel-basiert oder Apple-Silicon-basiert. Standardmäßig generiert das Build-Skript von ONNX Runtime nur Bits für die CPU-ARCH, die die Build-Maschine hat. Wenn Sie cross-kompilieren möchten: generieren Sie arm64-Binaries auf einem Intel-basierten Mac-Computer oder generieren Sie x86-Binaries auf einem Mac-System mit Apple Silicon, können Sie die CMake-Variable "CMAKE_OSX_ARCHITECTURES" setzen. Zum Beispiel
Build für Intel-CPUs
./build.sh --config RelWithDebInfo --build_shared_lib --parallel --compile_no_warning_as_error --skip_submodule_sync --cmake_extra_defines CMAKE_OSX_ARCHITECTURES=x86_64
Build für Apple-Silicon-CPUs
./build.sh --config RelWithDebInfo --build_shared_lib --parallel --compile_no_warning_as_error --skip_submodule_sync --cmake_extra_defines CMAKE_OSX_ARCHITECTURES=arm64
Build für beide
./build.sh --config RelWithDebInfo --build_shared_lib --parallel --compile_no_warning_as_error --skip_submodule_sync --cmake_extra_defines CMAKE_OSX_ARCHITECTURES="x86_64;arm64"
Der letzte Befehl generiert ein Fat-Binary für beide CPU-Architekturen.
Hinweis: Unit-Tests werden aufgrund des inkompatiblen CPU-Befehlssatzes beim Cross-Kompilieren übersprungen.
AIX
Unter AIX können Sie ONNX Runtime für 64 Bit erstellen mit
- IBM Open XL Compiler Toolchain. Die minimal erforderliche AIX OS-Version ist 7.2. Sie benötigen die Compiler-PTF5-Version 17.1.2 (17.1.2.5).
- GNU GCC Compiler Toolchain. Die minimal erforderliche AIX OS-Version ist 7.3. GCC-Version 10.3+ ist erforderlich.
Für IBM Open XL exportieren Sie untenstehende Umgebungseinstellungen.
ulimit -m unlimited
ulimit -d unlimited
ulimit -n 2000
ulimit -f unlimited
export OBJECT_MODE=64
export BUILD_TYPE="Release"
export CC="/opt/IBM/openxlC/17.1.2/bin/ibm-clang"
export CXX="/opt/IBM/openxlC/17.1.2/bin/ibm-clang++_r"
export CFLAGS="-pthread -m64 -D_ALL_SOURCE -mcmodel=large -Wno-deprecate-lax-vec-conv-all -Wno-unused-but-set-variable -Wno-unused-command-line-argument -maltivec -mvsx -Wno-unused-variable -Wno-unused-parameter -Wno-sign-compare"
export CXXFLAGS="-pthread -m64 -D_ALL_SOURCE -mcmodel=large -Wno-deprecate-lax-vec-conv-all -Wno-unused-but-set-variable -Wno-unused-command-line-argument -maltivec -mvsx -Wno-unused-variable -Wno-unused-parameter -Wno-sign-compare"
export LDFLAGS="-L$PWD/build/Linux/$BUILD_TYPE/ -lpthread"
export LIBPATH="$PWD/build/Linux/$BUILD_TYPE/"
Für GCC exportieren Sie untenstehende Umgebungseinstellungen.
ulimit -m unlimited
ulimit -d unlimited
ulimit -n 2000
ulimit -f unlimited
export OBJECT_MODE=64
export BUILD_TYPE="Release"
export CC="gcc"
export CXX="g++"
export CFLAGS="-maix64 -pthread -DFLATBUFFERS_LOCALE_INDEPENDENT=0 -maltivec -mvsx -Wno-unused-function -Wno-unused-variable -Wno-unused-parameter -Wno-sign-compare -fno-extern-tls-init -Wl,-berok "
export CXXFLAGS="-maix64 -pthread -DFLATBUFFERS_LOCALE_INDEPENDENT=0 -maltivec -mvsx -Wno-unused-function -Wno-unused-variable -Wno-unused-parameter -Wno-sign-compare -fno-extern-tls-init -Wl,-berok "
export LDFLAGS="-L$PWD/build/Linux/$BUILD_TYPE/ -Wl,-bbigtoc -lpython3.9"
export LIBPATH="$PWD/build/Linux/$BUILD_TYPE"
Um den Build zu starten, führen Sie den folgenden Befehl aus:
./build.sh \
--config $BUILD_TYPE\
--build_shared_lib \
--skip_submodule_sync \
--cmake_extra_defines CMAKE_INSTALL_PREFIX=$PWD/install \
--parallel
- Wenn Sie das Paket in einem benutzerdefinierten Verzeichnis installieren möchten, geben Sie den Verzeichnispfad als Wert von CMAKE_INSTALL_PREFIX an.
- Bei der IBM Open XL Compiler Toolchain fehlen unter AIX 7.2 möglicherweise einige Laufzeitbibliotheken wie libunwind.a, die für onnxruntime benötigt werden. Um dies zu beheben, können Sie die relevanten Dateisätze installieren.
- --parallel-Option in den Build-Optionen. Wie der Name schon sagt, ist diese Option für parallele Builds und ressourcenintensive Optionen gedacht. Wenn Ihr System nicht über genügend Arbeitsspeicher pro CPU-Kern verfügt, kann diese Option übersprungen werden.
- --allow_running_as_root wird benötigt, wenn der Root-Benutzer den Build auslöst.
Hinweise
- Bitte beachten Sie, dass diese Anweisungen den Debug-Build erstellen, der Leistungseinbußen haben kann. Der Parameter "--config" hat vier gültige Werte: Debug, Release, RelWithDebInfo und MinSizeRel. Im Vergleich zu "Release" enthält "RelWithDebInfo" nicht nur Debug-Informationen, sondern deaktiviert auch einige Inlines, um das Binary leichter debuggen zu können. Daher ist RelWithDebInfo langsamer als Release.
- Um die Version aus jedem Release zu erstellen (die Windows-, Linux- und Mac-Varianten enthält), siehe diese .yml-Dateien als Referenz.
- Das Build-Skript führt standardmäßig alle Unit-Tests für native Builds aus und überspringt Tests standardmäßig für cross-kompilierte Builds. Um die Tests zu überspringen, führen Sie mit
--buildoder--update --buildaus. - Wenn Sie Protobuf aus dem Quellcode installieren müssen, beachten Sie bitte
- Öffnen Sie zuerst cmake/deps.txt, um zu prüfen, welche Protobuf-Version die offiziellen Pakete von ONNX Runtime verwenden.
- Da wir Protobuf statisch verlinken, sollte unter Windows das CMake-Flag
protobuf_BUILD_SHARED_LIBSauf AUS gesetzt sein. Unter Linux, wenn die Option AUS ist, müssen Sie auch sicherstellen, dass PIC aktiviert ist. Nach der Installation sollten Sie die ausführbare Datei "protoc" in Ihrem PATH haben. Es wird empfohlen,ldconfigauszuführen, um sicherzustellen, dass die Protobuf-Bibliotheken gefunden werden. - Wenn Sie Protobuf an einem nicht standardmäßigen Speicherort installiert haben, ist es hilfreich, die folgende Umgebungsvariable festzulegen:
export CMAKE_ARGS="-DONNX_CUSTOM_PROTOC_EXECUTABLE=full path to protoc", damit der ONNX-Build es finden kann. Führen Sie auchldconfig <protobuf lib folder path>aus, damit der Linker die Protobuf-Bibliotheken findet.
- Wenn Sie onnx aus dem Quellcode installieren möchten, installieren Sie zuerst Protobuf und
export ONNX_ML=1 python3 setup.py bdist_wheel pip3 install --upgrade dist/*.whlDann ist es besser, Protobuf zu deinstallieren, bevor Sie mit dem Erstellen von ONNX Runtime beginnen, insbesondere wenn Sie eine andere Version von Protobuf als ONNX Runtime installiert haben. —
Unterstützte Architekturen und Build-Umgebungen
Architekturen
| x86_32 | x86_64 | ARM32v7 | ARM64 | PPC64LE | RISCV64 | PPC64BE | S390X | |
|---|---|---|---|---|---|---|---|---|
| Windows | JA | JA | JA | JA | NEIN | NEIN | NEIN | NEIN |
| Linux | JA | JA | JA | JA | JA | JA | NEIN | JA |
| macOS | NEIN | JA | NEIN | NEIN | NEIN | NEIN | NEIN | NEIN |
| Android | NEIN | NEIN | JA | JA | NEIN | NEIN | NEIN | NEIN |
| iOS | NEIN | NEIN | NEIN | JA | NEIN | NEIN | NEIN | NEIN |
| AIX | NEIN | NEIN | NEIN | NEIN | NEIN | NEIN | JA | NEIN |
Build-Umgebungen (Host)
| OS | Unterstützt CPU | Unterstützt GPU | Hinweise |
|---|---|---|---|
| Windows 10 | JA | JA | VS2019 bis zum neuesten VS2022 werden unterstützt |
| Windows 10 Subsystem for Linux | JA | NEIN | |
| Ubuntu 20.x/22.x | JA | JA | Ebenfalls unterstützt auf ARM32v7 (experimentell) |
| CentOS 7/8/9 | JA | JA | Ebenfalls unterstützt auf ARM32v7 (experimentell) |
| macOS | JA | NEIN |
GCC 8.x und darunter werden nicht unterstützt.
Wenn Sie ein Binary für eine 32-Bit-Architektur erstellen möchten, müssen Sie möglicherweise cross-kompilieren, da ein 32-Bit-Compiler möglicherweise nicht über genügend Speicher verfügt, um den Build auszuführen.
Das Erstellen des Codes unter Android/iOS wird nicht unterstützt. Sie müssen ein Windows-, Linux- oder macOS-Gerät verwenden, um dies zu tun.
| Betriebssystem/Compiler | Unterstützt VC | Unterstützt GCC | Unterstützt Clang |
|---|---|---|---|
| Windows 10 | JA | Nicht getestet | Nicht getestet |
| Linux | NEIN | JA (gcc>=8) | Nicht getestet |
| macOS | NEIN | Nicht getestet | JA (Mindestversion nicht ermittelt) |
Zielumgebungen
Sie können den Code für
- Windows
- Linux
- MacOS
- Android
- iOS
- WebAssembly
Laufzeit
- Die minimal unterstützte Windows-Version ist Windows 10.
- Die minimal unterstützte CentOS-Version ist 7.
- Die minimal unterstützte Ubuntu-Version ist 16.04.
Allgemeine Build-Anweisungen
| Beschreibung | Befehl | Zusätzliche Details |
|---|---|---|
| Grundlegender Build | build.bat (Windows)./build.sh (Linux) | |
| Release-Build | --config Release | Release-Build. Andere gültige Konfigurationswerte sind RelWithDebInfo und Debug. |
| Build mit paralleler Verarbeitung | --parallel | Dies wird dringend empfohlen, um den Build zu beschleunigen. |
| Freigegebene Bibliothek erstellen | --build_shared_lib | |
| Training-Unterstützung aktivieren | --enable_training |
APIs und Sprachbindungen
| API | Befehl | Zusätzliche Details |
|---|---|---|
| Python | --build_wheel | |
| C#- und C-Nuget-Pakete | --build_nuget | Erstellt C#-Bindungen und erstellt ein Nuget-Paket. Impliziert --build_shared_libDetaillierte Anweisungen finden Sie weiter unten. |
| WindowsML | --use_winml--use_dml--build_shared_lib | WindowsML hängt von DirectML und der freigegebenen ONNX Runtime-Bibliothek ab. |
| Java | --build_java | Erstellt ein onnxruntime4j.jar im Build-Verzeichnis, impliziert --build_shared_libZum Kompilieren der Java-API ist Gradle v6.1+ zusätzlich zu den üblichen Anforderungen erforderlich. |
| Node.js | --build_nodejs | Erstellt Node.js-Bindung. Impliziert --build_shared_lib |
Nuget-Pakete erstellen
Derzeit nur unter Windows und Linux unterstützt.
Voraussetzungen
- dotnet wird zum Erstellen von C#-Bindungen und zum Erstellen von verwalteten Nuget-Paketen benötigt. Befolgen Sie die Anweisungen hier, um dotnet herunterzuladen. Getestet mit den Versionen 2.1 und 3.1.
- nuget.exe. Befolgen Sie die Anweisungen hier, um nuget herunterzuladen.
- Unter Windows ist das Herunterladen von nuget unkompliziert, und das Befolgen der obigen Anweisungen sollte ausreichen.
- Unter Linux ist nuget auf Mono-Laufzeit angewiesen, daher muss dies ebenfalls eingerichtet werden. Der obige Link enthält alle Informationen zur Einrichtung von Mono und nuget. Die Anweisungen finden Sie direkt hier. In einigen Fällen ist es erforderlich, nach der Installation von mono
sudo apt-get install mono-completeauszuführen.
Bauanleitungen
Windows
.\build.bat --build_nuget
Linux
./build.sh --build_nuget
Nuget-Pakete werden erstellt unter
Weitere Build-Optionen
- Sie können onnxruntime mit VCPKG erstellen. Das Dokument /docs/build/dependencies.md enthält weitere Informationen dazu.
Build mit reduzierten Operator-Kernen
Reduzierte Operator-Kerne-Builds ermöglichen es Ihnen, die Kerne im Build anzupassen, um kleinere Binärgrößen zu erzielen.
DebugNodeInputsOutputs
OnnxRuntime unterstützt Build-Optionen zur Aktivierung des Debugging von Zwischen-Tensorformen und -daten.
Build-Anweisungen
Setzen Sie onnxruntime_DEBUG_NODE_INPUTS_OUTPUT, um mit aktivierter Funktion zu erstellen.
Linux
./build.sh --cmake_extra_defines onnxruntime_DEBUG_NODE_INPUTS_OUTPUTS=1
Windows
.\build.bat --cmake_extra_defines onnxruntime_DEBUG_NODE_INPUTS_OUTPUTS=1
Konfiguration
Das Verhalten des Debug-Dumps kann mit mehreren Umgebungsvariablen gesteuert werden. Details finden Sie unter onnxruntime/core/framework/debug_node_inputs_outputs_utils.h.
Beispiele
Um anzugeben, dass die Ausgabe von Knotendaten gedumpt werden soll (standardmäßig an stdout), setzen Sie diese Umgebungsvariable.
ORT_DEBUG_NODE_IO_DUMP_OUTPUT_DATA=1
Um anzugeben, dass Knotenausgabedaten für Knoten mit dem Namen "Foo" oder "Bar" in Dateien gedumpt werden sollen, setzen Sie diese Umgebungsvariablen.
ORT_DEBUG_NODE_IO_DUMP_OUTPUT_DATA=1
ORT_DEBUG_NODE_IO_NAME_FILTER="Foo;Bar"
ORT_DEBUG_NODE_IO_DUMP_DATA_TO_FILES=1
RISC-V
Die Ausführung auf einer Plattform wie RISC-V beinhaltet das Cross-Kompilieren von einer Host-Plattform (z. B. Linux) auf eine Zielplattform (eine spezifische RISC-V-CPU-Architektur und ein Betriebssystem). Befolgen Sie die untenstehenden Anweisungen, um ONNX Runtime für RISC-V 64-Bit zu erstellen.
Cross-Kompilierung unter Linux
-
Laden Sie die GNU RISC-V Cross-Compile-Toolchain und den Emulator herunter und installieren Sie sie.
Wenn Sie Ubuntu verwenden, können Sie eine vorcompilierte RISC-V GNU-Toolchain erhalten, indem Sie https://github.com/riscv-collab/riscv-gnu-toolchain/releases besuchen. Suchen Sie nach der entsprechenden Version, z. B.
riscv64-glibc-ubuntu-22.04-llvm-nightly-XXXX-nightly.tar.gz. Extrahieren Sie nach dem Herunterladen das Archiv auf Ihre Build-Maschine und fügen Sie den Ordner "bin" zu Ihrer $PATH-Umgebungsvariable hinzu. Der QEMU-Emulator befindet sich ebenfalls im Toolchain-Ordner. Überspringen Sie diesen Schritt, wenn Sie diese Anweisungen befolgt haben.Für Benutzer mit anderen Linux-Distributionen besteht die Möglichkeit, GCC aus seinem Quellcode zu kompilieren. Es wird empfohlen, eine Compiler-Version zu wählen, die Ihrem Zielbetriebssystem entspricht, und die neueste stabile Version zu wählen.
Wenn Sie den Compiler erhalten, führen Sie
riscv64-unknown-linux-gnu-gcc -vaus. Dies sollte eine Ausgabe wie die folgende erzeugen:Using built-in specs. COLLECT_GCC=/path/to/riscv64-unknown-linux-gnu-gcc COLLECT_LTO_WRAPPER=/path/to/libexec/gcc/riscv64-unknown-linux-gnu/13.2.0/lto-wrapper Target: riscv64-unknown-linux-gnu Configured with: /path/to/riscv-gnu-toolchain/gcc/configure --target=riscv64-unknown-linux-gnu --prefix=/opt/riscv --with-sysroot=/opt/riscv/sysroot --with-pkgversion= --with-system-zlib --enable-shared --enable-tls --enable-languages=c,c++,fortran --disable-libmudflap --disable-libssp --disable-libquadmath --disable-libsanitizer --disable-nls --disable-bootstrap --src=.././gcc --disable-multilib --with-abi=lp64d --with-arch=rv64gc --with-tune=rocket --with-isa-spec=20191213 'CFLAGS_FOR_TARGET=-O2 -mcmodel=medlow' 'CXXFLAGS_FOR_TARGET=-O2 -mcmodel=medlow' Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 13.2.0 () -
Konfigurieren der RISC-V 64-Bit CMake-Toolchain-Datei
Die CMake-Toolchain-Datei befindet sich unter
${ORT_ROOT}/cmake/riscv64.toolchain.cmake. Wenn es alternative Werte für die Variable gibt, die konfiguriert werden müssen, fügen Sie bitte die entsprechenden Einstellungen in diese Datei ein. -
Cross-Kompilierung unter Linux
Führen Sie
./build.shmit dem Flag--rv64aus, geben Sie das RISC-V-Toolchain-Root mit--riscv_toolchain_rootund den QEMU-Pfad mit--riscv_qemu_pathals Build-Optionen an, um den Build-Prozess zu starten. Stellen Sie sicher, dass alle installierten Cross-Compiler von der Befehlszeile aus zugänglich sind, die zum Erstellen verwendet wird, indem Sie diePATH-Umgebungsvariable konfigurieren.(Optional) Wenn Sie xnnpack als Ausführungsanbieter verwenden möchten, stellen Sie sicher, dass Sie die Option
--use_xnnpackin Ihre Build-Konfiguration aufnehmen.Beispiel für einen Build-Befehl
./build.sh --parallel --config Debug --rv64 --riscv_toolchain_root=/path/to/toolchain/root --riscv_qemu_path=/path/to/qemu-riscv64 --skip_tests
Arm
Es gibt mehrere Optionen zum Erstellen von ONNX Runtime für ARM®-basierte Geräte.
Zuerst können Sie dies auf einem echten ARM-basierten Gerät tun, oder auf einem x86_64-Gerät mit einem Emulator (wie qemu), oder auf einem x86_64-Gerät mit einem Docker-Container mit einem Emulator (Sie können einen ARM-basierten Container auf einem x86_64-PC ausführen). Dann sind die Build-Anweisungen im Wesentlichen dieselben wie die Anweisungen für Linux x86_64. Dies funktioniert jedoch nicht, wenn die CPU, auf die Sie abzielen, nicht 64-Bit ist, da der Build-Prozess mehr als 2 GB Speicher benötigt.
- Cross-Kompilierung für ARM-basierte Geräte mit Simulation (Linux/Windows) - **Empfohlen**; Einfach, langsam, nur ARM64 (keine Unterstützung für ARM32)
- Cross-Kompilierung unter Linux - Schwierig, schnell
- Cross-Kompilierung unter Windows
Cross-Kompilierung für ARM-basierte Geräte mit Simulation (Linux/Windows)
EINFACH, LANGSAM, EMPFOHLEN
Diese Methode basiert auf der Emulation im QEMU-Benutzermodus. Sie ermöglicht Ihnen, mit einer Desktop- oder Cloud-VM durch Instruktionslevel-Simulation zu kompilieren. Sie führen den Build auf einer x86-CPU aus und übersetzen jede ARM-Architektur-Instruktion in x86. Dies ist potenziell viel schneller als das native Kompilieren auf einem Low-End-Gerät. Die resultierende ONNX Runtime Python Wheel (.whl)-Datei wird dann auf ein ARM-basiertes Gerät bereitgestellt, wo sie in Python 3-Skripten aufgerufen werden kann. Der Build-Prozess kann Stunden dauern und es kann zu Speicherengpässen kommen, wenn die Ziel-CPU 32-Bit ist.
Cross-Kompilierung unter Linux
Schwierig, schnell
Diese Option ist sehr schnell und ermöglicht es, das Paket in wenigen Minuten zu erstellen, ist aber schwierig einzurichten. Wenn Sie eine große Codebasis haben (z. B. wenn Sie einen neuen Ausführungsanbieter zu onnxruntime hinzufügen), kann dies die einzig praktikable Methode sein.
-
Holen Sie sich die entsprechende Toolchain.
TLDR; Gehen Sie zu https://www.linaro.org/downloads/, holen Sie sich "64-Bit Armv8 Cortex-A, Little-Endian" und "Linux Targeted", nicht "Bare-Metal Targeted". Extrahieren Sie es auf Ihre Build-Maschine und fügen Sie den bin-Ordner zu Ihrer $PATH-Umgebungsvariable hinzu. Überspringen Sie dann diesen Teil.
Sie können GCC oder Clang verwenden. Beide funktionieren, aber die Anweisungen hier basieren auf GCC.
In GCC-Begriffen
- "build" beschreibt die Art des Systems, auf dem GCC konfiguriert und kompiliert wird.
- "host" beschreibt die Art des Systems, auf dem GCC läuft.
- "target" beschreibt die Art des Systems, für das GCC Code erzeugt.
Wenn nicht cross-kompiliert wird, ist normalerweise "build" = "host" = "target". Wenn Sie cross-kompilieren, ist normalerweise "build" = "host" != "target". Zum Beispiel können Sie GCC auf x86_64 erstellen, dann GCC auf x86_64 ausführen und dann Binaries generieren, die auf aarch64 abzielen. In diesem Fall ist "build" = "host" = x86_64 Linux, target ist aarch64 Linux.
Sie können entweder GCC selbst aus dem Quellcode erstellen oder eine vorcompilierte Version von einem Anbieter wie Ubuntu oder Linaro erhalten. Die Wahl derselben Compilerversion wie Ihr Zielbetriebssystem ist am besten. Wenn dies nicht möglich ist, wählen Sie die neueste stabile Version und verlinken Sie statisch auf die GCC-Bibliotheken.
Wenn Sie den Compiler erhalten, führen Sie
aarch64-linux-gnu-gcc -vaus. Dies sollte eine Ausgabe wie die folgende erzeugen:Using built-in specs. COLLECT_GCC=/usr/bin/aarch64-linux-gnu-gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/aarch64-linux-gnu/9/lto-wrapper Target: aarch64-linux-gnu Configured with: ../gcc-9.2.1-20190827/configure --bindir=/usr/bin --build=x86_64-redhat-linux-gnu --datadir=/usr/share --disable-decimal-float --disable-dependency-tracking --disable-gold --disable-libgcj --disable-libgomp --disable-libmpx --disable-libquadmath --disable-libssp --disable-libunwind-exceptions --disable-shared --disable-silent-rules --disable-sjlj-exceptions --disable-threads --with-ld=/usr/bin/aarch64-linux-gnu-ld --enable-__cxa_atexit --enable-checking=release --enable-gnu-unique-object --enable-initfini-array --enable-languages=c,c++ --enable-linker-build-id --enable-lto --enable-nls --enable-obsolete --enable-plugin --enable-targets=all --exec-prefix=/usr --host=x86_64-redhat-linux-gnu --includedir=/usr/include --infodir=/usr/share/info --libexecdir=/usr/libexec --localstatedir=/var --mandir=/usr/share/man --prefix=/usr --program-prefix=aarch64-linux-gnu- --sbindir=/usr/sbin --sharedstatedir=/var/lib --sysconfdir=/etc --target=aarch64-linux-gnu --with-bugurl=https://bugzilla.redhat.com/bugzilla/ --with-gcc-major-version-only --with-isl --with-newlib --with-plugin-ld=/usr/bin/aarch64-linux-gnu-ld --with-sysroot=/usr/aarch64-linux-gnu/sys-root --with-system-libunwind --with-system-zlib --without-headers --enable-gnu-indirect-function --with-linker-hash-style=gnu Thread model: single gcc version 9.2.1 20190827 (Red Hat Cross 9.2.1-3) (GCC)Überprüfen Sie den Wert von
--build,--host,--targetund ob er spezielle Argumente wie--with-arch=armv8-a,--with-arch=armv6,--with-tune=arm1176jz-s,--with-fpu=vfp,--with-float=hardhat.Sie müssen auch wissen, welche Flags Ihre Zielhardware benötigt, was stark variieren kann. Zum Beispiel, wenn Sie nur den normalen ARMv7-Compiler erhalten und ihn direkt für Raspberry Pi V1 verwenden, funktioniert er nicht, da Raspberry Pi nur ARMv6 hat. Im Allgemeinen liefert jeder Hardwarehersteller eine Toolchain; prüfen Sie, wie diese erstellt wurde.
Eine Zielumgebung wird identifiziert durch
- Arch: x86_32, x86_64, armv6,armv7,arvm7l,aarch64,...
- OS: bare-metal oder linux.
- Libc: gnu libc/ulibc/musl/...
- ABI: Arm hat mehrere ABIs wie eabi, eabihf...
Sie können all diese Informationen aus der vorherigen Ausgabe erhalten, stellen Sie bitte sicher, dass sie alle korrekt sind.
-
(Optional) Sysroot einrichten, um Python-Erweiterungen zu aktivieren. *Überspringen, wenn Sie kein Python verwenden.*
Laden Sie das Root-Dateisystem des Zielbetriebssystems auf Ihre Build-Maschine. Wir nennen diesen Ordner "sysroot" und verwenden ihn für den Build der ONNX Runtime Python-Erweiterung. Bevor Sie dies tun, sollten Sie zuerst das Python3-Entwicklungspaket (das die C-Header-Dateien enthält) und das NumPy-Python-Paket auf der Zielmaschine installieren.
Hier sind einige Beispiele.
Wenn das Ziel-OS Raspbian-Buster ist, laden Sie bitte das RAW-Image von ihrer Website herunter und führen Sie dann aus:
$ fdisk -l 2020-02-13-raspbian-buster.imgDisk 2020-02-13-raspbian-buster.img: 3,54 GiB, 3787456512 Bytes, 7397376 Sektoren Einheiten: Sektoren von 1 * 512 = 512 Bytes Sektorgröße (logisch/physikalisch): 512 Bytes / 512 Bytes E/A-Größe (minimal/optimal): 512 Bytes / 512 Bytes Disklabel-Typ: dos Disk-Identifikator: 0xea7d04d6
Gerät Boot Start Ende Sektoren Größe ID Typ 2020-02-13-raspbian-buster.img1 8192 532479 524288 256M c W95 FAT32 (LBA) 2020-02-13-raspbian-buster.img2 532480 7397375 6864896 3,3G 83 Linux Sie werden feststellen, dass die Root-Partition bei Sektor 532480 beginnt, was 532480 * 512 = 272629760 Bytes vom Anfang entfernt ist.
Führen Sie dann aus:
$ mkdir /mnt/pi $ mount -r -o loop,offset=272629760 2020-02-13-raspbian-buster.img /mnt/piSie sehen alle Raspbian-Dateien unter /mnt/pi. Sie können es jedoch noch nicht verwenden. Da einige der Symlinks defekt sind, müssen Sie sie zuerst reparieren.
Führen Sie unter /mnt/pi aus:
$ find . -type l -exec realpath {} \; |grep 'No such file'Dies zeigt, welche defekt sind. Dann können Sie sie reparieren, indem Sie ausführen:
$ mkdir /mnt/pi2 $ cd /mnt/pi2 $ sudo tar -C /mnt/pi -cf - . | sudo tar --transform 'flags=s;s,^/,/mnt/pi2/,' -xf -Dann ist /mnt/pi2 der Sysroot-Ordner, den Sie im nächsten Schritt verwenden werden.
Wenn das Ziel-OS Ubuntu ist, können Sie ein Image von https://cloud-images.ubuntu.com/ erhalten. Aber dieses Image ist im qcow2-Format. Konvertieren Sie es bitte, bevor Sie fdisk ausführen und mounten.
qemu-img convert -p -O raw ubuntu-18.04-server-cloudimg-arm64.img ubuntu.rawDer restliche Teil ist ähnlich wie bei Raspbian.
Wenn das Ziel-OS manylinux2014 ist, können Sie es erhalten durch: Installieren Sie qemu-user-static über apt oder dnf. Führen Sie dann den Docker aus:
Ubuntu
docker run -v /usr/bin/qemu-aarch64-static:/usr/bin/qemu-aarch64-static -it --rm quay.io/pypa/manylinux2014_aarch64 /bin/bashDas Argument "-v /usr/bin/qemu-aarch64-static:/usr/bin/qemu-aarch64-static" ist unter Fedora nicht erforderlich.
Führen Sie dann innerhalb des Dockers Folgendes aus:
cd /opt/python ./cp35-cp35m/bin/python -m pip install numpy==1.16.6 ./cp36-cp36m/bin/python -m pip install numpy==1.16.6 ./cp37-cp37m/bin/python -m pip install numpy==1.16.6 ./cp38-cp38/bin/python -m pip install numpy==1.16.6Diese Befehle werden einige Stunden dauern, da NumPy noch kein vorcompiliertes Paket hat. Wenn sie abgeschlossen sind, öffnen Sie ein zweites Fenster und führen Sie aus:
docker psAus der Ausgabe
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 5a796e98db05 quay.io/pypa/manylinux2014_aarch64 "/bin/bash" 3 minutes ago Up 3 minutes affectionate_cannonSie sehen die Docker-Instanz-ID: 5a796e98db05. Verwenden Sie den folgenden Befehl, um das Root-Dateisystem als Sysroot für zukünftige Verwendung zu exportieren.
docker export 5a796e98db05 -o manylinux2014_aarch64.tar -
Generieren Sie CMake-Toolchain-Datei Speichern Sie den folgenden Inhalt als tool.cmake
SET(CMAKE_SYSTEM_NAME Linux) SET(CMAKE_SYSTEM_VERSION 1) SET(CMAKE_C_COMPILER aarch64-linux-gnu-gcc) SET(CMAKE_CXX_COMPILER aarch64-linux-gnu-g++) SET(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER) SET(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY) SET(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY) SET(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY) SET(CMAKE_FIND_ROOT_PATH /mnt/pi)Wenn Sie keinen Sysroot haben, können Sie die letzte Zeile löschen.
Außerdem können Sie CMAKE_SYSTEM_PROCESSOR setzen. Die offizielle Dokumentation von CMake empfiehlt, bei der Cross-Kompilierung eine CMAKE_TOOLCHAIN_FILE-Datei zu verwenden, um die Variable CMAKE_SYSTEM_PROCESSOR auf die Zielarchitektur einzustellen, die sie angibt. Die Dokumentation listet jedoch keine gültigen Werte auf, und wir haben festgestellt, dass diese Einstellung nicht notwendig ist. Wenn Sie wissen, auf welchen Wert die Variable gesetzt werden sollte, fügen Sie die Einstellung dort hinzu. Die Build-Skripte von ONNX Runtime verwenden diese Variable nicht, aber die Abhängigkeiten von ONNX Runtime möglicherweise.
-
Führen Sie CMake und Make aus
Hängen Sie
-Donnxruntime_ENABLE_CPUINFO=OFF -DCMAKE_TOOLCHAIN_FILE=path/to/tool.cmakean Ihre CMake-Argumente an, führen Sie CMake und Make aus, um es zu erstellen. Wenn Sie auch ein Python-Paket erstellen möchten, können Sie CMake-Argumente wie folgt verwenden:-Donnxruntime_GCC_STATIC_CPP_RUNTIME=ON -DCMAKE_BUILD_TYPE=Release -Dprotobuf_WITH_ZLIB=OFF -DCMAKE_TOOLCHAIN_FILE=path/to/tool.cmake -Donnxruntime_ENABLE_PYTHON=ON -DPYTHON_EXECUTABLE=/mnt/pi/usr/bin/python3 -Donnxruntime_BUILD_SHARED_LIB=OFF -Donnxruntime_DEV_MODE=OFF "-DPYTHON_INCLUDE_DIR=/mnt/pi/usr/include;/mnt/pi/usr/include/python3.7m" -DNUMPY_INCLUDE_DIR=/mnt/pi/folder/to/numpy/headersNachdem Sie CMake ausgeführt haben, führen Sie aus:
$ make -
(Optional) Python-Paket erstellen
Kopieren Sie die setup.py-Datei aus dem Quellordner in den Build-Ordner und führen Sie aus:
python3 setup.py bdist_wheel -p linux_aarch64Wenn Sie auf ManyLinux abzielen, funktionieren deren Tools im Cross-Kompilierungsszenario leider nicht. Führen Sie es in einem Docker wie diesem aus:
docker run -v /usr/bin/qemu-aarch64-static:/usr/bin/qemu-aarch64-static -v `pwd`:/tmp/a -w /tmp/a --rm quay.io/pypa/manylinux2014_aarch64 /opt/python/cp37-cp37m/bin/python3 setup.py bdist_wheelDies ist nicht erforderlich, wenn Sie nur eine bestimmte Linux-Distribution (z. B. Ubuntu) anvisieren möchten.
Cross-Kompilierung unter Windows
Verwendung von Visual C++ Compilern
-
Laden Sie Visual C++ Compiler und Bibliotheken für Arm (64) herunter und installieren Sie sie. Wenn Sie Visual Studio installiert haben, verwenden Sie den Visual Studio Installer (suchen Sie im Abschnitt
Individuelle Komponenten, nachdem Sie Visual Studioändernausgewählt haben), um die entsprechenden Arm (64)-Compiler und Bibliotheken herunterzuladen und zu installieren. -
Verwenden Sie
.\build.batund geben Sie--armoder--arm64als Build-Option an, um mit dem Erstellen zu beginnen. Bevorzugen Sie die Verwendung derDeveloper Command Prompt for VSoder stellen Sie sicher, dass alle installierten Cross-Compiler von der Befehlszeile, die zum Erstellen verwendet wird, über die PATH-Umgebungsvariable auffindbar sind. -
Fügen Sie
--use_vcpkgzu Ihrem Build-Befehl hinzu, was die manuelle Handhabung von protoc.exe vermeiden kann.
Mobile
Bitte siehe Build für Android und Build für iOS.
Web
Bitte siehe Build für Web.