cross
v0.2.5
crossCompilation croisée «zéro configuration» et «tests croisés» des caisses de rouille
Ce projet est développé et entretenu par l'équipe Cross-RS. Il a été précédemment entretenu par l'équipe Rust Embedded Group Tools. Les nouveaux contributeurs sont les bienvenus! Veuillez rejoindre notre salle de matrice et dire bonjour.
`Cross Test 'une caisse pour la cible AARCH64-Sundown-Linux-GNU
cross fournira tous les ingrédients nécessaires à la compilation croisée sans toucher à l'installation de votre système.
cross fournit un environnement, une chaine de croix et des bibliothèques compilées compilées, qui produisent les binaires les plus portables.
«Cross Testing», cross peut tester les caisses pour des architectures autres que les i686 et x86_64.
Les canaux stables, bêta et nocturnes sont soutenus.
Consultez notre guide de démarrage pour des instructions d'installation détaillées.
Un de ces moteurs à conteneurs est requis. Si les deux sont installés, cross sera par défaut à docker .
docker ou utiliser Docker sans racine. Lisez le guide d'installation du moteur de conteneur pour les étapes d'installation et de post-installation requises. Nécessite la version 20.10 (API 1.40) ou version ultérieure.cargo install cross --git https://github.com/cross-rs/crossIl est également possible de télécharger directement les binaires de libération pré-compilés ou d'utiliser la cargo-binstall.
cross a exactement la même CLI que la cargaison mais s'appuie sur Docker ou Podman. Pour Docker, vous devrez démarrer le démon avant de pouvoir l'utiliser.
# (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
Des documents supplémentaires peuvent être trouvés sur le wiki ou le docs/ sous-dossier.
Vous avez quatre options pour configurer cross . Toutes ces options utilisent le format Toml pour la configuration et les valeurs de configuration possibles sont documentées ici.
cross directement dans votre Cargo.toml Vous pouvez définir directement les valeurs de configuration dans votre fichier Cargo.toml , dans le tableau [workspace.metadata.cross] , c'est-à-dire préfixe de clé. Un exemple d'extrait de configuration ressemblerait à ceci:
[ 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 via un fichier Cross.toml Vous pouvez mettre votre configuration dans un fichier Cross.toml dans le répertoire racine de votre projet.
CROSS_CONFIG pour spécifier l'emplacement de votre configuration En définissant la variable d'environnement CROSS_CONFIG , vous pouvez dire cross où il doit rechercher le fichier de configuration. De cette façon, vous n'êtes pas limité à un fichier Cross.toml dans la racine du projet.
crossOutre les fichiers de configuration basés sur Toml, la configuration peut également être transmise à travers des variables d'environnement.
Lorsque vous exécutez cross à l'intérieur d'un conteneur, cross a besoin d'accès aux hôtes Docker Daemon lui-même. Ceci est normalement réalisé en montant le Docker Daemons Socket /var/run/docker.sock . Par exemple:
$ 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
L'image en cours d' cross nécessite l'installation des outils de développement de la rouille.
Avec cette cross il faut trouver et monter les chemins hôtes corrects dans le conteneur utilisé pour la compilation croisée. Cela comprend le répertoire de projet d'origine ainsi que le chemin racine du conteneur parent pour donner accès aux outils de construction de rouille.
Pour informer cross , il fonctionne à l'intérieur d'un conteneur set CROSS_CONTAINER_IN_CONTAINER=true .
Un conteneur de développement ou de CI peut être créé comme ceci:
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
...
Limites : La recherche du point de montage pour le répertoire racine des conteneurs est actuellement disponible uniquement pour le pilote de stockage de superposition. Afin d'accéder à la configuration de la rouille des conteneurs parents, le conteneur enfant monte les parents qui superdisent. Le parent ne doit pas être arrêté avant le conteneur enfant, car le super-imprécision ne peut pas être correctement non monté par Docker si le conteneur enfant y accède toujours.
Par défaut, cross essaie d'utiliser Docker ou Podman, dans cet ordre. Si vous souhaitez choisir explicitement un moteur à conteneurs, vous pouvez définir le nom (ou le chemin) binaire à l'aide de la variable d'environnement CROSS_CONTAINER_ENGINE .
Par exemple, au cas où vous souhaitez utiliser Podman, vous pouvez définir CROSS_CONTAINER_ENGINE=podman .
Une cible est considérée comme «soutenue» si cross peut compiler une caisse «non triviale» (binaire), généralement le fret, pour cette cible.
Le support de test ( cross test ) est plus compliqué. Il repose sur l'émulation QEMU, donc les tests peuvent échouer en raison de bogues Qemu plutôt que de bogues dans votre caisse. Cela dit, une cible a une ✓ dans la colonne test du tableau ci-dessous si elle peut exécuter la suite de test compiler-builtins .
De plus, le test est très lent. cross test exécute les unités teste séquentiellement parce que QEMU se fâche lorsque vous engendrez plusieurs threads. Cela signifie que, si l'un de vos tests unitaires engendre des threads, alors il est plus susceptible d'échouer ou, pire, de ne jamais se terminer.
| Cible | 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; Ne fonctionne qu'avec des tests natifs, c'est-à-dire des tests qui ne dépend pas de l'exécution d'Android. Pour i686, certains tests peuvent échouer avec l'erreur assertion failed: signal(libc::SIGPIPE, libc::SIG_IGN) != libc::SIG_ERR , voir le numéro 140 pour plus d'informations.
[2] Aucun composant std disponible.
[3] Pour certaines cibles * BSD et Solaris, la colonne LIBC indique la version de version du système d'exploitation à partir de laquelle LIBC a été extraite.
[4] libc = newlib
[5] doit changer image = "ghcr.io/cross-rs/x86_64-unknown-linux-gnu:main-centos" dans Cross.toml pour [target.x86_64-unknown-linux-gnu] pour utiliser la cible compatible CentOS7.
[6] libc = emscripten et gcc = clang
[7] doit changer image = "ghcr.io/cross-rs/aarch64-unknown-linux-gnu:main-centos" dans Cross.toml pour [target.aarch64-unknown-linux-gnu] pour utiliser la cible compatible CentOS7.
Des docker supplémentaires pour d'autres cibles peuvent être trouvés dans les chaures croisées. Il s'agit notamment des cibles MSVC et Apple Darwin, dont nous ne pouvons pas expédier des images prédéfinies.
Vous pouvez définir la variable Qemu_Strace lorsque vous utilisez cross run pour obtenir une droite des appels système à partir de binaires «étrangers» (non x86_64).
$ 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)
Cette caisse est garantie pour compiler sur une rouille stable 1,77,2 et plus. Il peut se compiler avec des versions plus anciennes, mais cela peut changer dans toute nouvelle version de patch.
Certaines cibles de compilation transversale nécessitent une version de rouille ultérieure, et l'utilisation de Xargo nécessite une chaîne d'outils de rouille nocturne.
Sous licence sous l'un ou l'autre des
à votre option.
À moins que vous ne soyez explicitement indiqué autrement, toute contribution intentionnellement soumise pour inclusion dans les travaux par vous, telle que définie dans la licence Apache-2.0, doit être autorisée à double licence comme ci-dessus, sans aucune condition supplémentaire.
La contribution à cette caisse est organisée en vertu des termes du code de conduite de la rouille, le mainteneur de cette caisse, l'équipe Cross-RS, promet d'intervenir pour maintenir ce code de conduite.
