cross
v0.2.5
crossCompilação cruzada de “Zero Setup” e “teste cruzado” de caixas de ferrugem
Este projeto é desenvolvido e mantido pela equipe Cross-RS. Foi mantido anteriormente pela equipe de ferramentas de grupo de trabalho incorporado à ferrugem. Novos colaboradores são bem -vindos! Por favor, junte -se à nossa sala Matrix e diga oi.
`Cross Test`ing A Crate for the Aarch64-Uknown-Linux-Gnu Target
cross fornecerá todos os ingredientes necessários para a compilação cruzada sem tocar na instalação do sistema.
cross fornece um ambiente, uma cadeia de ferramentas cruzadas e bibliotecas compiladas cruzadas, que produz os binários mais portáteis.
“Teste cruzado”, cross pode testar caixas para arquiteturas que não sejam i686 e x86_64.
Os canais estáveis, beta e noturnos são suportados.
Consulte nosso guia de início para obter instruções detalhadas de instalação.
Um desses motores de contêiner é necessário. Se ambos estiverem instalados, cross será o padrão para docker .
docker ou usar o Docker sem raízes. Leia o guia de instalação do mecanismo de contêineres para as etapas de instalação e pós-instalação necessárias. Requer a versão 20.10 (API 1.40) ou posterior.cargo install cross --git https://github.com/cross-rs/crossTambém é possível baixar diretamente os binários de lançamento pré-compilados ou usar o Cargo-Binstall.
cross tem exatamente o mesmo CLI da carga, mas depende do Docker ou Podman. Para o Docker, você terá que iniciar o daemon antes de poder usá -lo.
# (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
Documentação adicional pode ser encontrada no wiki ou nos docs/ subpasta.
Você tem quatro opções para configurar cross . Todas essas opções usam o formato TOML para configuração e os possíveis valores de configuração são documentados aqui.
cross diretamente em sua Cargo.toml Você pode definir diretamente os valores de configuração no seu arquivo Cargo.toml , na tabela [workspace.metadata.cross] , ou seja, prefixo -chave. Um exemplo de snippet de configuração ficaria assim:
[ 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 através de um arquivo Cross.toml Você pode colocar sua configuração dentro de um arquivo Cross.toml no diretório raiz do seu projeto.
CROSS_CONFIG para especificar o local da sua configuração Ao definir a variável de ambiente CROSS_CONFIG , você pode dizer cross onde deve procurar o arquivo de configuração. Dessa forma, você não está limitado a um arquivo Cross.toml na raiz do projeto.
cross através de variáveis de ambienteAlém dos arquivos de configuração baseados em TOML, a configuração também pode ser passada através de variáveis de ambiente.
Ao correr cross de dentro de um recipiente, cross precisa de acesso ao próprio daemon do Docker Hosts. Isso normalmente é alcançado montando o soquete do Docker Daemons /var/run/docker.sock . Por exemplo:
$ 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
A cross de imagem requer que as ferramentas de desenvolvimento da ferrugem sejam instaladas.
Com essa cross de configuração, deve encontrar e montar os caminhos corretos do host no recipiente usado para compilação cruzada. Isso inclui o diretório original do projeto, bem como o caminho raiz do contêiner pai para dar acesso às ferramentas de construção de ferrugem.
Para informar cross que ele está sendo executado dentro de um conjunto de contêineres CROSS_CONTAINER_IN_CONTAINER=true .
Um desenvolvimento ou contêiner de IC pode ser criado assim:
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
...
LIMITAÇÕES : Encontrar o ponto de montagem para o diretório raiz dos contêineres está atualmente disponível apenas para o driver de armazenamento OverlayFS2. Para acessar a configuração de ferrugem dos contêineres pais, o recipiente infantil monta os pais sobrepostos. O pai não deve ser interrompido antes do recipiente filho, pois os sobrepositores não podem ser desmontados corretamente pelo Docker se o recipiente infantil ainda o acessar.
Por padrão, cross tenta usar o Docker ou o Podman, nessa ordem. Se você deseja escolher explicitamente um mecanismo de contêiner, poderá definir o nome binário (ou caminho) usando a variável de ambiente CROSS_CONTAINER_ENGINE .
Por exemplo, caso você queira usar o Podman, você pode definir CROSS_CONTAINER_ENGINE=podman .
Um alvo é considerado como "suportado" se cross puder atravessar uma caixa "não trivial" (binária), geralmente carga, para esse alvo.
O suporte ao teste ( cross test ) é mais complicado. Ele depende da emulação de Qemu, portanto, os testes podem falhar devido a bugs qemu, em vez de bugs em sua caixa. Dito isto, um alvo possui uma coluna de test da tabela abaixo se puder executar o conjunto de testes compiler-builtins .
Além disso, o teste é muito lento. cross test é executado nos testes de unidades sequencialmente porque o Qemu fica chateado quando você gera vários threads. Isso significa que, se um de seus testes de unidade gera threads, é mais provável que falhe ou, pior, nunca termine.
| Alvo | 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 / D | ✓ |
i586-unknown-linux-musl | 1.2.3 | 9.2.0 | ✓ | N / D | ✓ |
i686-unknown-freebsd | 1.5 | 6.4.0 | ✓ | N / D | |
i686-linux-android [1] | 9.0.8 | 9.0.8 | ✓ | 6.1.0 | ✓ |
i686-pc-windows-gnu | N / D | 9.4 | ✓ | N / D | ✓ |
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 / D | |
thumbv6m-none-eabi [4] | 3.3.0 | 9.2.1 | N / D | ||
thumbv7em-none-eabi [4] | 3.3.0 | 9.2.1 | N / D | ||
thumbv7em-none-eabihf [4] | 3.3.0 | 9.2.1 | N / D | ||
thumbv7m-none-eabi [4] | 3.3.0 | 9.2.1 | N / D | ||
thumbv7neon-linux-androideabi [1] | 9.0.8 | 9.0.8 | ✓ | 6.1.0 | ✓ |
thumbv7neon-unknown-linux-gnueabihf | 2.31 | 9.4.0 | ✓ | N / D | ✓ |
thumbv8m.base-none-eabi [4] | 3.3.0 | 9.2.1 | N / D | ||
thumbv8m.main-none-eabi [4] | 3.3.0 | 9.2.1 | N / D | ||
thumbv8m.main-none-eabihf [4] | 3.3.0 | 9.2.1 | N / D | ||
wasm32-unknown-emscripten [6] | 3.1.14 | 15.0.0 | ✓ | N / D | ✓ |
x86_64-linux-android [1] | 9.0.8 | 9.0.8 | ✓ | 6.1.0 | ✓ |
x86_64-pc-windows-gnu | N / D | 9.3 | ✓ | N / D | ✓ |
x86_64-pc-solaris | 1.22.7 | 8.4.0 | ✓ | N / D | |
x86_64-unknown-freebsd | 1.5 | 6.4.0 | ✓ | N / D | |
x86_64-unknown-dragonfly [2] [3] | 6.0.1 | 10.3.0 | ✓ | N / D | |
x86_64-unknown-illumos | 1.20.4 | 8.4.0 | ✓ | N / D | |
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 / D | ✓ |
x86_64-unknown-netbsd [3] | 9.2.0 | 9.4.0 | ✓ | N / D |
[1] libc = bionic; Funciona apenas com testes nativos, ou seja, testes que não dependem do tempo de execução do Android. Para i686, alguns testes podem falhar com a assertion failed: signal(libc::SIGPIPE, libc::SIG_IGN) != libc::SIG_ERR , consulte a edição nº 140 para obter mais informações.
[2] Nenhum componente std disponível.
[3] Para alguns alvos *BSD e Solaris, a coluna LIBC indica a versão de liberação do OS da qual a LIBC foi extraída.
[4] libc = newlib
[5] deve alterar image = "ghcr.io/cross-rs/x86_64-unknown-linux-gnu:main-centos" em Cross.toml para [target.x86_64-unknown-linux-gnu] para usar o alvo compatível com centros7.
[6] libc = emscriptten e gcc = clang
[7] deve alterar image = "ghcr.io/cross-rs/aarch64-unknown-linux-gnu:main-centos" em Cross.toml para [target.aarch64-unknown-linux-gnu] para usar o alvo compatível com centros7.
Dockerfiles adicionais para outros alvos podem ser encontrados em tools cruzados. Isso inclui alvos MSVC e Apple Darwin, dos quais não podemos enviar imagens pré-construídas.
Você pode definir a variável QEMU_STRACE quando usa cross run para obter um backtrace de chamadas do sistema de binários "estrangeiros" (não 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)
Esta caixa é garantida para compilar a ferrugem estável 1,77.2 e acima. Pode compilar com versões mais antigas, mas isso pode mudar em qualquer nova versão do patch.
Alguns alvos de compilação cruzada requerem uma versão de ferrugem posterior, e o uso de Xargo requer uma cadeia de ferramentas de ferrugem noturna.
Licenciado sob qualquer um de
por sua opção.
A menos que você declare explicitamente o contrário, qualquer contribuição enviada intencionalmente para inclusão no trabalho por você, conforme definido na licença Apache-2.0, será licenciado como acima, sem termos ou condições adicionais.
A contribuição para esta caixa é organizada nos termos do Código de Conduta Rust, o mantenedor desta caixa, a equipe Cross-RS, promete intervir para defender esse código de conduta.
