cross
v0.2.5
crossCross Compilation und Cross -Tests von Rostkisten "Zero Setup"
Dieses Projekt wird vom Cross-RS-Team entwickelt und gepflegt. Es wurde zuvor vom Rost -Embedded Working Group Tools -Team gepflegt. Neue Mitwirkende sind willkommen! Bitte nehmen Sie an unserem Matrixraum bei und sagen Sie Hallo.
`Cross test` Eine Kiste für das AARG64-UNKNOWN-LINUX-GNU-Ziel
cross liefert alle für die Querkompilierung benötigten Zutaten, ohne die Installation der Systeminstallation zu berühren.
cross bietet eine Umgebung, eine Cross Toolchain und eine Cross -kompilierte Bibliotheken, die die tragbarsten Binärdateien erzeugt.
"Cross Testing", cross kann Kisten für andere Architekturen als i686 und x86_64 testen.
Die Stall-, Beta- und nächtlichen Kanäle werden unterstützt.
In unserem Erste -Start -Leitfaden finden Sie detaillierte Installationsanweisungen.
Eine dieser Containermotoren ist erforderlich. Wenn beide installiert sind, wird cross standardmäßig docker .
docker -Gruppe sein oder rootless Docker verwenden müssen. Lesen Sie die Installationsanleitung für Containermotoren für die erforderlichen Installations- und Nachinstallationsschritte. Benötigt Version 20.10 (API 1.40) oder höher.cargo install cross --git https://github.com/cross-rs/crossEs ist auch möglich, die vorgefertigten Release-Binärdateien direkt herunterzuladen oder Fracht-Binstall zu verwenden.
cross hat genau die gleiche CLI wie Fracht, stützt sich jedoch auf Docker oder Podman. Für Docker müssen Sie den Daemon starten, bevor Sie ihn verwenden können.
# (ONCE PER BOOT, on Linux)
# Start the Docker daemon, if it's not already running using systemd
# on WSL2 and other systems using SysVinit, use `sudo service docker start`.
$ sudo systemctl start docker
# MAGIC! This Just Works
$ cross build --target aarch64-unknown-linux-gnu
# EVEN MORE MAGICAL! This also Just Works
$ cross test --target mips64-unknown-linux-gnuabi64
# Obviously, this also Just Works
$ cross rustc --target powerpc-unknown-linux-gnu --release -- -C lto
Zusätzliche Dokumentation finden Sie auf dem Wiki oder dem docs/ dem Unterordner.
Sie haben vier Optionen zum Konfigurieren von cross . Alle diese Optionen verwenden das TOML -Format für die Konfiguration und die möglichen Konfigurationswerte werden hier dokumentiert.
cross direkt in Ihrer Cargo.toml Sie können Konfigurationswerte in Ihrer Datei Cargo.toml unter der Tabelle [workspace.metadata.cross] , dh Schlüsselpräfix, direkt festlegen. Ein Beispiel -Konfigurations -Snippet würde so aussehen:
[ workspace . metadata . cross . target . aarch64-unknown-linux-gnu ]
# Install libssl-dev:arm64, see <https://github.com/cross-rs/cross/blob/main/docs/custom_images.md#adding-dependencies-to-existing-images>
pre-build = [
" dpkg --add-architecture $CROSS_DEB_ARCH " ,
" apt-get update && apt-get --assume-yes install libssl-dev:$CROSS_DEB_ARCH "
]
[ workspace . metadata . cross . target . armv7-unknown-linux-gnueabi ]
image = " my/image:latest "
[ workspace . metadata . cross . build ]
env.volumes = [ " A_DIRECTORY=/path/to/volume " ]cross über eine Cross.toml -Datei Sie können Ihre Konfiguration in eine Cross.toml -Datei in Ihr Projektroot -Verzeichnis einfügen.
CROSS_CONFIG um den Speicherort Ihrer Konfiguration anzugeben Durch Einstellen der Variablen CROSS_CONFIG -Umgebungsvariablen können Sie cross erkennen, wo es nach der Konfigurationsdatei suchen soll. Auf diese Weise sind Sie nicht auf eine Cross.toml -Datei im Projektstamm beschränkt.
cross -durch -UmgebungsvariablenNeben den TOML-basierten Konfigurationsdateien kann auch Konfiguration durch Umgebungsvariablen weitergeleitet werden.
Beim Laufen von cross von innerhalb eines Containers benötigt cross Zugriff auf den Hosts Docker -Daemon selbst. Dies wird normalerweise durch die Montage des Docker Daemons Socket /var/run/docker.sock erreicht. Zum Beispiel:
$ docker run -v /var/run/docker.sock:/var/run/docker.sock -v .:/project
-w /project my/development-image:tag cross build --target mips64-unknown-linux-gnuabi64
Für das mit dem Bild laufende cross müssen die Tools für Rustentwicklung installiert werden.
Mit diesem Setup muss cross die richtigen Hostpfade in den für die Querkompilierung verwendeten Behälter finden und montieren. Dies schließt das ursprüngliche Projektverzeichnis sowie den Stammpfad des übergeordneten Containers ein, um Zugriff auf die Rost -Build -Werkzeuge zu erhalten.
Um cross zu informieren, dass es in einem Container set CROSS_CONTAINER_IN_CONTAINER=true .
Ein Entwicklungs- oder CI -Behälter kann so erstellt werden:
FROM rust:1
# set CROSS_CONTAINER_IN_CONTAINER to inform `cross` that it is executed from within a container
ENV CROSS_CONTAINER_IN_CONTAINER=true
# install `cross`
RUN cargo install cross
...
Einschränkungen : Das Finden des Mountspunkts für das Root -Verzeichnis Container ist derzeit nur für den OverlayFS2 -Speicher -Treiber verfügbar. Um auf das Rost -Setup der Eltern Container zuzugreifen, montiert die Eltern die Eltern Overlayfs. Der Elternteil darf nicht vor dem untergeordneten Container gestoppt werden, da die OverlayFs von Docker nicht korrekt nicht unmontiert werden können, wenn der untergeordnete Container darauf zugreift.
Standardmäßig versucht cross , Docker oder Podman in dieser Reihenfolge zu verwenden. Wenn Sie einen Containermotor explizit auswählen möchten, können Sie den binären Namen (oder den Pfad) mit der Umgebungsvariablen CROSS_CONTAINER_ENGINE festlegen.
Wenn Sie beispielsweise Podman verwenden möchten, können Sie CROSS_CONTAINER_ENGINE=podman festlegen.
Ein Ziel wird als „unterstützt“ angesehen, wenn cross eine „nicht triviale“ (binäre) Kiste, normalerweise Fracht für dieses Ziel, zusammenstellen kann.
Die Testunterstützung ( cross test ) ist komplizierter. Es stützt sich auf die QEMU -Emulation, sodass das Testen möglicherweise aufgrund von QEMU -Fehler und nicht aufgrund von Fehler in Ihrer Kiste fehlschlägt. Ein Ziel hat jedoch eine ✓ In test der folgenden Tabelle, wenn es die compiler-builtins Testsuite ausführen kann.
Auch das Testen ist sehr langsam. cross test -Einheiten -Tests werden nacheinander, weil QEMU beim Erschaffenen mehrerer Threads verärgert wird. Dies bedeutet, dass, wenn einer Ihrer Unit -Tests Threads hervorbringt, es wahrscheinlicher ist, dass er nicht endet oder, schlimmste, niemals endet.
| Ziel | libc | GCC | C ++ | Qemu | test |
|---|---|---|---|---|---|
aarch64-linux-android [1] | 9.0.8 | 9.0.8 | ✓ | 6.1.0 | ✓ |
aarch64-unknown-linux-gnu | 2.31 | 9.4.0 | ✓ | 6.1.0 | ✓ |
aarch64-unknown-linux-gnu:centos [7] | 2.17 | 4.8.5 | 4.2.1 | ✓ | |
aarch64-unknown-linux-musl | 1.2.3 | 9.2.0 | ✓ | 6.1.0 | ✓ |
arm-linux-androideabi [1] | 9.0.8 | 9.0.8 | ✓ | 6.1.0 | ✓ |
arm-unknown-linux-gnueabi | 2.31 | 9.4.0 | ✓ | 6.1.0 | ✓ |
arm-unknown-linux-gnueabihf | 2.31 | 8.5.0 | ✓ | 6.1.0 | ✓ |
arm-unknown-linux-musleabi | 1.2.3 | 9.2.0 | ✓ | 6.1.0 | ✓ |
arm-unknown-linux-musleabihf | 1.2.3 | 9.2.0 | ✓ | 6.1.0 | ✓ |
armv5te-unknown-linux-gnueabi | 2.31 | 9.4.0 | ✓ | 6.1.0 | ✓ |
armv5te-unknown-linux-musleabi | 1.2.3 | 9.2.0 | ✓ | 6.1.0 | ✓ |
armv7-linux-androideabi [1] | 9.0.8 | 9.0.8 | ✓ | 6.1.0 | ✓ |
armv7-unknown-linux-gnueabi | 2.31 | 9.4.0 | ✓ | 6.1.0 | ✓ |
armv7-unknown-linux-gnueabihf | 2.31 | 9.4.0 | ✓ | 6.1.0 | ✓ |
armv7-unknown-linux-musleabi | 1.2.3 | 9.2.0 | ✓ | 6.1.0 | ✓ |
armv7-unknown-linux-musleabihf | 1.2.3 | 9.2.0 | ✓ | 6.1.0 | ✓ |
i586-unknown-linux-gnu | 2.31 | 9.4.0 | ✓ | N / A | ✓ |
i586-unknown-linux-musl | 1.2.3 | 9.2.0 | ✓ | N / A | ✓ |
i686-unknown-freebsd | 1.5 | 6.4.0 | ✓ | N / A | |
i686-linux-android [1] | 9.0.8 | 9.0.8 | ✓ | 6.1.0 | ✓ |
i686-pc-windows-gnu | N / A | 9.4 | ✓ | N / A | ✓ |
i686-unknown-linux-gnu | 2.31 | 9.4.0 | ✓ | 6.1.0 | ✓ |
loongarch64-unknown-linux-gnu | 2.36 | 14.2.0 | ✓ | 8.2.2 | ✓ |
loongarch64-unknown-linux-musl | 1.2.5 | 14.2.0 | ✓ | 8.2.2 | ✓ |
mips-unknown-linux-gnu | 2.30 | 9.4.0 | ✓ | 6.1.0 | ✓ |
mips-unknown-linux-musl | 1.2.3 | 9.2.0 | ✓ | 6.1.0 | ✓ |
mips64-unknown-linux-gnuabi64 | 2.30 | 9.4.0 | ✓ | 6.1.0 | ✓ |
mips64-unknown-linux-muslabi64 | 1.2.3 | 9.2.0 | ✓ | 6.1.0 | ✓ |
mips64el-unknown-linux-gnuabi64 | 2.30 | 9.4.0 | ✓ | 6.1.0 | ✓ |
mips64el-unknown-linux-muslabi64 | 1.2.3 | 9.2.0 | ✓ | 6.1.0 | ✓ |
mipsel-unknown-linux-gnu | 2.30 | 9.4.0 | ✓ | 6.1.0 | ✓ |
mipsel-unknown-linux-musl | 1.2.3 | 9.2.0 | ✓ | 6.1.0 | ✓ |
powerpc-unknown-linux-gnu | 2.31 | 9.4.0 | ✓ | 6.1.0 | ✓ |
powerpc64-unknown-linux-gnu | 2.31 | 9.4.0 | ✓ | 6.1.0 | ✓ |
powerpc64le-unknown-linux-gnu | 2.31 | 9.4.0 | ✓ | 6.1.0 | ✓ |
riscv64gc-unknown-linux-gnu | 2.35 | 11.4.0 | ✓ | 8.2.2 | ✓ |
s390x-unknown-linux-gnu | 2.31 | 9.4.0 | ✓ | 6.1.0 | ✓ |
sparc64-unknown-linux-gnu | 2.31 | 9.4.0 | ✓ | 6.1.0 | ✓ |
sparcv9-sun-solaris | 1.22.7 | 8.4.0 | ✓ | N / A | |
thumbv6m-none-eabi [4] | 3.3.0 | 9.2.1 | N / A | ||
thumbv7em-none-eabi [4] | 3.3.0 | 9.2.1 | N / A | ||
thumbv7em-none-eabihf [4] | 3.3.0 | 9.2.1 | N / A | ||
thumbv7m-none-eabi [4] | 3.3.0 | 9.2.1 | N / A | ||
thumbv7neon-linux-androideabi [1] | 9.0.8 | 9.0.8 | ✓ | 6.1.0 | ✓ |
thumbv7neon-unknown-linux-gnueabihf | 2.31 | 9.4.0 | ✓ | N / A | ✓ |
thumbv8m.base-none-eabi [4] | 3.3.0 | 9.2.1 | N / A | ||
thumbv8m.main-none-eabi [4] | 3.3.0 | 9.2.1 | N / A | ||
thumbv8m.main-none-eabihf [4] | 3.3.0 | 9.2.1 | N / A | ||
wasm32-unknown-emscripten [6] | 3.1.14 | 15.0.0 | ✓ | N / A | ✓ |
x86_64-linux-android [1] | 9.0.8 | 9.0.8 | ✓ | 6.1.0 | ✓ |
x86_64-pc-windows-gnu | N / A | 9.3 | ✓ | N / A | ✓ |
x86_64-pc-solaris | 1.22.7 | 8.4.0 | ✓ | N / A | |
x86_64-unknown-freebsd | 1.5 | 6.4.0 | ✓ | N / A | |
x86_64-unknown-dragonfly [2] [3] | 6.0.1 | 10.3.0 | ✓ | N / A | |
x86_64-unknown-illumos | 1.20.4 | 8.4.0 | ✓ | N / A | |
x86_64-unknown-linux-gnu | 2.31 | 9.4.0 | ✓ | 6.1.0 | ✓ |
x86_64-unknown-linux-gnu:centos [5] | 2.17 | 4.8.5 | ✓ | 4.2.1 | ✓ |
x86_64-unknown-linux-musl | 1.2.3 | 9.2.0 | ✓ | N / A | ✓ |
x86_64-unknown-netbsd [3] | 9.2.0 | 9.4.0 | ✓ | N / A |
[1] libc = bionic; Funktioniert nur mit nativen Tests, dh Tests, die nicht von der Android -Laufzeit abhängen. Für i686 können einige Tests mit der assertion failed: signal(libc::SIGPIPE, libc::SIG_IGN) != libc::SIG_ERR
[2] Keine std -Komponente verfügbar.
[3] Für einige *BSD- und Solaris -Ziele gibt die LIBC -Spalte die OS -Release -Version an, aus der LIBC extrahiert wurde.
[4] libc = newlib
[5] MUSS image = "ghcr.io/cross-rs/x86_64-unknown-linux-gnu:main-centos" in Cross.toml für [target.x86_64-unknown-linux-gnu] ändern, um das CentOS7-kompatible Ziel zu verwenden.
[6] libc = emscripten und gcc = klang
[7] MUSS image = "ghcr.io/cross-rs/aarch64-unknown-linux-gnu:main-centos" in Cross.toml für [target.aarch64-unknown-linux-gnu] ändern, um das Centos7-kompatible Ziel zu verwenden.
Zusätzliche Dockerfiles für andere Ziele finden Sie in Cross-Toolchains. Dazu gehören MSVC- und Apple Darwin-Ziele, von denen wir nicht vorgefertigte Bilder versenden können.
Sie können die variable qemu_strace festlegen, wenn Sie cross run verwenden, um eine Backtrace von Systemaufrufen aus "Fremd" -Binärzungen (Non x86_64) zu erhalten.
$ cargo new --bin hello && cd $_
$ QEMU_STRACE=1 cross run --target aarch64-unknown-linux-gnu
9 brk(NULL) = 0x0000004000023000
9 uname(0x4000823128) = 0
(..)
9 write(1,0xa06320,14)Hello, world!
= 14
9 sigaltstack(0x4000823588,(nil)) = 0
9 munmap(0x0000004000b16000,16384) = 0
9 exit_group(0)
Diese Kiste wird garantiert auf stabilen Rost 1,77,2 und up zusammenstellen. Es könnte mit älteren Versionen kompiliert werden, aber das kann sich in jeder neuen Patch -Version ändern.
Einige Cross-Compilation-Ziele erfordern eine spätere Rostversion, und die Verwendung von Xargo benötigt eine nächtliche Rost-Toolchain.
Lizenziert unter einem von
nach Ihrer Option.
Sofern Sie nicht ausdrücklich anders angeben, ist ein Beitrag, der absichtlich zur Aufnahme in die Arbeit von Ihnen eingereicht wird, wie in der Apache-2.0-Lizenz definiert, ohne zusätzliche Bedingungen doppelt lizenziert wie oben.
Der Beitrag zu dieser Kiste ist nach den Bestimmungen des Rost-Verhaltenskodex, des Betreuers dieser Kiste, des Cross-RS-Teams, verspricht, diesen Verhaltenskodex aufrechtzuerhalten.
