cross
v0.2.5
cross"Configuración cero" compilación cruzada y "prueba cruzada" de las cajas de óxido
Este proyecto es desarrollado y mantenido por el equipo de RS-RS. Anteriormente fue mantenido por el equipo de herramientas de trabajo de trabajo integrado de Rust. ¡Los nuevos contribuyentes son bienvenidos! Únase a nuestra habitación de matriz y saluda.
`Cross Test 'una caja para el objetivo AARCH64-ONDNOWN-LINUX-GNU
cross proporcionará todos los ingredientes necesarios para la compilación cruzada sin tocar la instalación de su sistema.
cross proporciona un entorno, una cadena de herramientas cruzadas y bibliotecas cruzadas compiladas, que produce los binarios más portátiles.
"Pruebas cruzadas", cross puede probar cajas de arquitecturas distintas de i686 y x86_64.
Los canales estables, beta y nocturnos son compatibles.
Consulte nuestra guía de inicio para obtener instrucciones de instalación detalladas.
Se requiere uno de estos motores de contenedores. Si ambos están instalados, cross será predeterminado a docker .
docker o usar Docker Rootless. Lea la guía de instalación del motor del contenedor para los pasos de instalación y posterior a la instalación requeridos. Requiere la versión 20.10 (API 1.40) o posterior.cargo install cross --git https://github.com/cross-rs/crossTambién es posible descargar directamente los binarios de liberación precompilados o usar la binstall de carga.
cross tiene exactamente el mismo CLI que la carga, pero depende de Docker o Podman. Para Docker, tendrá que comenzar el demonio antes de poder usarlo.
# (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
Se puede encontrar documentación adicional en el wiki o los docs/ subcarpetas.
Tiene cuatro opciones para configurar cross . Todas estas opciones utilizan el formato TomL para la configuración y los posibles valores de configuración se documentan aquí.
cross directamente en su Cargo.toml Puede establecer directamente los valores de configuración en su archivo Cargo.toml , en la tabla [workspace.metadata.cross] , IE Key Prefix. Un fragmento de configuración de ejemplo se vería así:
[ 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 a través de un archivo Cross.toml Puede colocar su configuración dentro de un archivo Cross.toml en su directorio raíz de proyecto.
CROSS_CONFIG para especificar la ubicación de su configuración Al configurar la variable de entorno CROSS_CONFIG , puede decirle cross dónde debe buscar el archivo de configuración. De esta manera, no se limita a un archivo Cross.toml en la raíz del proyecto.
cross a través deAdemás de los archivos de configuración basados en TOML, la configuración también se puede pasar a través de variables de entorno.
Cuando se ejecuta cross desde el interior de un contenedor, cross necesita acceso a los hosts Docker Daemon. Esto normalmente se logra al montar el socket /var/run/docker.sock de Docker Daemons. Por ejemplo:
$ 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
La imagen que ejecuta cross requiere que se instalen las herramientas de desarrollo de óxido.
Con esta cross de configuración, debe encontrar y montar las rutas de host correctas en el contenedor utilizado para la compilación cruzada. Esto incluye el directorio de proyecto original, así como la ruta raíz del contenedor principal para dar acceso a las herramientas de construcción de óxido.
Para informar cross que se está ejecutando dentro de un contenedor set CROSS_CONTAINER_IN_CONTAINER=true .
Se puede crear un contenedor de desarrollo o CI como este:
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
...
Limitaciones : Encontrar el punto de montaje para el directorio de raíz de contenedores actualmente solo está disponible para el controlador de almacenamiento OverlayFS2. Para acceder a la configuración de los contenedores de los padres, el contenedor infantil monta los padres superpuestos. El padre no debe detenerse antes del contenedor infantil, ya que Docker no puede desmontar correctamente los superpuestos si el contenedor infantil todavía lo accede.
Por defecto, cross intenta usar Docker o Podman, en ese orden. Si desea elegir un motor de contenedor explícitamente, puede establecer el nombre binario (o ruta) utilizando la variable de entorno CROSS_CONTAINER_ENGINE .
Por ejemplo, en caso de que desee usar Podman, puede configurar CROSS_CONTAINER_ENGINE=podman .
Un objetivo se considera "compatible" si cross puede compilar una caja "no trivial" (binaria), generalmente carga, para ese objetivo.
El soporte de pruebas ( cross test ) es más complicado. Se basa en la emulación de QEMU, por lo que las pruebas pueden fallar debido a errores QEMU en lugar de errores en su caja. Dicho esto, un objetivo tiene un ✓ en la columna test de la tabla a continuación si puede ejecutar la suite de prueba compiler-builtins .
Además, las pruebas son muy lentas. cross test ejecuta las pruebas de unidades secuencialmente porque QEMU se enoja cuando genera múltiples hilos. Esto significa que, si una de sus pruebas unitarias genera hilos, entonces es más probable que falle o, lo peor, nunca termine.
| Objetivo | 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 = biónico; Solo funciona con pruebas nativas, es decir, pruebas que no dependen del tiempo de ejecución de Android. Para i686, algunas pruebas pueden fallar con la assertion failed: signal(libc::SIGPIPE, libc::SIG_IGN) != libc::SIG_ERR , consulte el número 140 para obtener más información.
[2] No hay componente std disponible.
[3] Para algunos objetivos *BSD y Solaris, la columna LIBC indica la versión de liberación del sistema operativo de la cual se extrajo LIBC.
[4] libc = newlib
[5] debe cambiar image = "ghcr.io/cross-rs/x86_64-unknown-linux-gnu:main-centos" en Cross.toml para [target.x86_64-unknown-linux-gnu] para usar el objetivo compatible con centos7.
[6] libc = emscripten y gcc = clang
[7] debe cambiar image = "ghcr.io/cross-rs/aarch64-unknown-linux-gnu:main-centos" en Cross.toml para [target.aarch64-unknown-linux-gnu] para usar el objetivo compatible con centos7.
Dockerfiles adicionales para otros objetivos se pueden encontrar en las hojas cruzadas. Estos incluyen objetivos MSVC y Apple Darwin, de los que no podemos enviar imágenes preconstruidas.
Puede establecer la variable QEMU_STRACE cuando usa cross run para obtener un retroceso de las llamadas del sistema desde binarios "extranjeros" (no 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)
Se garantiza que esta caja se compilará en el óxido estable 1.77.2 y más. Podría compilarse con versiones anteriores, pero eso puede cambiar en cualquier nuevo lanzamiento de parche.
Algunos objetivos de compilación cruzada requieren una versión de óxido posterior, y el uso de Xargo requiere una cadena de herramientas de óxido nocturna.
Con licencia bajo cualquiera de
a tu opción.
A menos que declare explícitamente lo contrario, cualquier contribución presentada intencionalmente para su inclusión en el trabajo por usted, como se define en la licencia Apache-2.0, se debe tener doble licencia como se indicó anteriormente, sin ningún término o condiciones adicionales.
La contribución a esta caja está organizada bajo los términos del Código de Conducta de Rust, el mantenedor de esta caja, el equipo de RS-RS, promete intervenir para defender ese código de conducta.
