Cross-compiling tools package guidelines (Português)

Status de tradução:
Esse artigo é uma tradução de
Cross-compiling tools package guidelines
. Data da última tradução: 2020-03-27. Você pode ajudar a sincronizar a tradução, se houver
alterações
na versão em inglês.
Diretrizes de pacotes do Arch
32-bit
–
CLR
–
CMake
–
Cross
–
DKMS
–
Eclipse
–
Electron
–
Fonte
–
Free Pascal
–
GNOME
–
Go
–
Haskell
–
Java
–
KDE
–
Kernel
–
Lisp
–
Meson
–
MinGW
–
Node.js
–
Nonfree
–
OCaml
–
Perl
–
PHP
–
Python
–
R
–
Ruby
–
Rust
–
Shell
–
VCS
–
Web
–
Wine
Essa página descreve como criar pacotes para cadeias de ferramentas de
compilador cruzado
. Outro método para compilação cruzada, faz uso de distcc em arquiteturas misturadas. Consulte
Distcc#Cross compiling with distcc
.
Dica
Como alternativa à criação de pacotes de compiladores cruzados, você poderia usar
crosstool-ng
e criar sua própria cadeia de ferramentas de maneira totalmente automatizada. crosstool-ng pode ser encontrado em
crosstool-ng
.
Nota importante
Esta página descreve a nova maneira de fazer as coisas, inspirada nos seguintes pacotes:
mingw-w64-gcc
e outros pacotes da série
mingw-w64-*
arm-none-eabi-gcc
e outros pacotes da série
arm-none-eabi-*
E outros pacotes da série
arm-wince-cegcc-*
Compatibilidade de versão
Atenção
O uso de versões incompatíveis de pacotes para compilação da cadeia de ferramentas leva a falhas inevitáveis. Por padrão, considere
todas
versões incompatíveis.
As seguintes estratégias permitem que você selecione versões compatíveis do gcc, binutils, kernel e biblioteca C:
Regras gerais:
existe uma correlação entre as versões gcc e binutils, use versões lançadas simultaneamente;
é melhor usar os cabeçalhos mais recentes do kernel para compilar a libc, mas use o opção
--enable-kernel
(específica da glibc, outras bibliotecas C podem usar convenções diferentes) para reforçar o funcionamento em kernels mais antigos;
Repositórios oficiais
: talvez seja necessário aplicar correções adicionais e hacks, mas as versões usadas pelo Arch Linux (ou seus forks específicos de arquitetura) provavelmente podem funcionar juntas;
Documentação de software: todo software GNU tem arquivos
README
e
NEWS
, documentando coisas como versões mínimas exigidas de dependências;
Outras distribuições: elas também fazem compilação cruzada;
https://clfs.org
cobre etapas necessárias para compilação de compilador cruzado e menciona versões um pouco atualizadas de dependências.
Compilando um compilador cruzado
A abordagem geral para construir um compilador cruzado é:
binutils: Compile um
cross-binutils
, que vincula e processa para a arquitetura de destino
cabeçalhos: Instale um conjunto de bibliotecas C e cabeçalhos de kernel para a arquitetura de destino
use
linux-api-headers
como referência e pesse
ARCH=
target-architecture
para o
make
crie um pacote de cabeçalhos libc (o processo para Glibc é descrito
aqui
[
link inativo
2024-01-13 ⓘ]
)
gcc-stage-1: Compile um compilador cruzado gcc básico (estágio 1). Isso será usado para compilar a biblioteca C. Ele não conseguirá compilar quase nada mais (porque ele não consegue se vincular à biblioteca C que ele não tem).
libc: Compile a biblioteca C "cross-compilada" (usando o compilador cruzado do estágio 1).
gcc-stage-2: Compile um compilador cruzado C completo (estágio 2)
O fonte dos cabeçalhos e libc podem variar conforme a plataforma.
Dica
O procedimento exato varia muito, dependendo das suas necessidades. Por exemplo, se você quiser criar um "clone" de um sistema Arch Linux com as mesmas versões de kernel e glibc, você pode pular cabeçalhos de construção e passar
--with-build-sysroot=/
para o
configure
.
Nomenclatura de pacote
O nome do pacote
não
deve ser prefixado com a palavra
cross-
(foi proposto anteriormente, mas não foi adotado em pacotes oficiais, provavelmente devido ao comprimento adicional de nomes), e consistirá do nome do pacote, prefixado por
trio GNU
sem campo de fornecedor ou com "desconhecido" no campo do fornecedor; exemplo:
arm-linux-gnueabihf-gcc
. Se houver uma convenção de nomenclatura mais curta (por exemplo,
mips-gcc
), ela poderá ser usada, mas isso não é recomendado.
Colocação de arquivos
As versões mais recentes do gcc e do binutils usam caminhos não conflitantes para sysroot e bibliotecas. Os executáveis devem ser colocados em
/usr/bin/
, para evitar conflitos aqui, prefixar todos eles com o nome da arquitetura.
Geralmente,
./configure
teria pelo menos os seguintes parâmetros:
_target=
seu_alvo
_sysroot=/usr/lib/${_target}
...
./configure \
    --prefix=${_sysroot} \
    --sysroot=${_sysroot} \
    --bindir=/usr/bin
sendo que
seu_alvo
pode ser, p. ex., "i686-pc-mingw32"
Exemplo
Esse é o PKGBUILD do binutils para MinGW. Coisas interessantes de se observar são:
especificar o diretório raiz do ambiente cruzado
o uso de variáveis
${_pkgname}
,
${_target}
e
${_sysroot}
para fazer o código mais legível
remoção de arquivos duplicados/conflitantes
# Maintainer: Allan McRae <allan@archlinux.org>

# cross toolchain build order: binutils, headers, gcc (pass 1), w32api, mingwrt, gcc (pass 2)

_target=i686-pc-mingw32
_sysroot=/usr/lib/${_target}

pkgname=${_target}-binutils
_pkgname=binutils
pkgver=2.19.1
pkgrel=1
pkgdesc="MinGW Windows binutils"
arch=('i686' 'x86_64')
url="http://www.gnu.org/software/binutils/"
license=('GPL')
depends=('glibc>=2.10.1' 'zlib')
options=('!libtool' '!distcc' '!ccache')
source=(http://ftp.gnu.org/gnu/${_pkgname}/${_pkgname}-${pkgver}.tar.bz2)
md5sums=('09a8c5821a2dfdbb20665bc0bd680791')

build() {
  cd ${srcdir}/${_pkgname}-${pkgver}
  mkdir binutils-build && cd binutils-build

  ../configure --prefix=${_sysroot} --bindir=/usr/bin \
    --with-sysroot=${_sysroot} \
    --build=$CHOST --host=$CHOST --target=${_target} \
    --with-gcc --with-gnu-as --with-gnu-ld \
    --enable-shared --without-included-gettext \
    --disable-nls --disable-debug --disable-win32-registry
  make
  make DESTDIR=${pkgdir}/ install

  # clean-up cross compiler root
  rm -r ${pkgdir}/${_sysroot}/{info,man}
}
Nota
Durante a compilação de cadeia de ferramentas cruzadas sempre execute os comandos
configure
e
make
a partir do diretório dedicado (chamada compilação fora da árvore) e remova todo o diretório
src
após a menor mudar em
PKGBUILD
.
Comos e por ques
Por que não instalar em
/opt
?
Dois motivos:
Primeiro, de acordo com o File Hierarchy Standard, esses arquivos pertencem apenas a um lugar no
/usr
.
Em segundo lugar, a instalação em
/opt
é a última medida quando não há outra opção.
O que é o negócio de
out-of-path executables
?
Essa coisa estranha facilita a compilação cruzada. Às vezes, os Makefiles do projeto não usam
CC
e outras variáveis e, em vez disso, usam
'gcc'
diretamente. Se você quiser apenas tentar compilar esse projeto, a edição do Makefile pode ser uma operação muito demorada. No entanto, alterar o
$PATH
para usar "nossos" executáveis primeiro é uma solução muito rápida. Você então executaria
PATH=/usr/
arch
/bin/:$PATH make
em vez de
make
.
Solução de problemas
O que fazer se a compilação falhar sem uma mensagem clara?
Para um erro ocorrido durante a execução do
configure
, leia
$srcdir/
pkgname
-build/config.log
. Para erro ocorrido durante compilação, role o log do console ou pesquise pela palavra "error".
O que esse erro [error message] significa?
Muito provavelmente você fez algum dos erros não óbvios:
Muitos ou poucos sinalizadores de configuração. Tente usar um conjunto já comprovadamente correto de sinalizadores.
As dependências estão corrompidas. Por exemplo, arquivos de binutils perdidos ou colocados no lugar errado podem resultar em erros ocultos durante a configuração do gcc.
Você não adicionou
export CFLAGS=""
à sua função
build()
(veja
bug 25672
no Bugzilla do GCC).
Algumas combinações
--prefix
/
--with-sysroot
podem exigir que diretórios sejam graváveis (não óbvias em guias de clfs).
sysroot ainda não tem cabeçalhos de kernel/libc.
Se google-fu não ajudar, abandone imediatamente sua configuração atual e tente uma mais estável e de funcionamento confirmado.
Por que os arquivos são instalados em lugares errados?
Vários métodos de execução da linha genérica
make install
acabam em resultados diferentes. Por exemplo, alguns destinos de make podem não fornecer suporte a
DESTDIR
e, em vez disso, requerem o uso de
install_root
. O mesmo para
tooldir
,
prefix
e outros argumentos semelhantes. Às vezes, fornecendo parâmetros como argumentos em vez de variáveis de ambiente, p. ex.
./configure CC=arm-elf-gcc
em vez de
CC=arm-elf-gcc ./configure
e vice-versa pode resultar em resultados diferentes (geralmente causados por auto-invocação recursiva de configure/make).
Veja também
https://wiki.osdev.org/GCC_Cross-Compiler