Buildroot Buildroot uso e documentação por Thomas Petazzoni. Contribuições de Karsten Kruse, Ludd Ned, Herren Martin e outros. • • • • • • • • • • • •
• • • • •
Sobre BuildRoot Obtenção BuildRoot Usando BuildRoot Personalizar o sistema de arquivos gerados alvo Personalizando a configuração Busybox Personalizando a configuração uClibc Personalizando a configuração do kernel Linux Compreensão de como reconstruir pacotes Como funciona BuildRoot Usando o uClibc BuildRoot fora toolchain Use um conjunto de ferramentas externas Usando ccache em BuildRoot Localização de pacotes baixados Adicionando novos pacotes BuildRoot Criar o seu próprio suporte de placa Perguntas mais frequentes Recursos
Sobre BuildRoot Buildroot é um conjunto de Makefiles e patches que permite que você facilmente gerar uma compilação cruzada toolchain, um sistema de arquivos raiz e uma imagem de kernel Linux para o seu alvo. Buildroot pode ser usado para uma, duas ou todas essas opções, de forma independente. Buildroot é útil principalmente para pessoas que trabalham com sistemas embarcados. Sistemas embarcados, muitas vezes usam processadores que não são os processadores x86 regulares todos estão acostumados a ter em seu PC. Podem ser processadores PowerPC, processadores MIPS, processadores ARM, etc Uma compilação toolchain é o conjunto de ferramentas que permite que você compilar o código para o seu sistema. Ele consiste de um compilador (no nosso caso, gcc ), utils binários como assembler e linker (no nosso caso, binutils ) e uma biblioteca C padrão (por exemplo Libc GNU , uClibc ou dietlibc ). O sistema instalado na sua estação de desenvolvimento, certamente já tem uma compilação toolchain que você pode usar para compilar uma aplicação que roda em seu sistema. Se você estiver usando um PC, suas corridas compilação toolchain em um processador x86 e gera código para um processador x86. Na maioria dos sistemas Linux, a compilação toolchain usa o GNU libc (glibc) como a biblioteca C padrão. Esta compilação toolchain é chamado de "compilação anfitrião toolchain". A máquina em que ele está sendo executado, e no qual você está trabalhando, é chamado de "sistema host". A compilação toolchain é fornecido por sua distribuição, e BuildRoot não tem nada a ver com isso (que não usá-lo para construir um ferramentas de compilação cruzada toolchain e outros que são executados na máquina de desenvolvimento). Como dito acima, a compilação toolchain que vem com o sistema rodando e gera o código para o processador no seu sistema host. Como seu sistema incorporado tem um processador diferente, você precisa de uma compilação cruzada toolchain - uma compilação toolchain que roda em seu sistema host, mas gera código para o seu sistema de destino (e processador de destino). Por exemplo, se seu sistema host x86 e usa seu sistema de destino usa ARM, a compilação regulares toolchain em seu
host roda em x86 e gera código para x86, enquanto os corta-mato-compilação toolchain em x86 e gera código para ARM. Mesmo que o seu sistema embarcado utiliza um processador x86, você poderia estar interessado em BuildRoot por duas razões: •
•
A compilação toolchain em seu host certamente usa a GNU libc que é um completo, mas enorme biblioteca C padrão. Em vez de usar Libc GNU no seu sistema alvo, você pode usar uClibc que é uma pequena biblioteca C padrão. Se você quiser usar esta biblioteca C, então você precisa de uma compilação toolchain para gerar os binários ligados com ele. Buildroot pode fazer isso por você. Buildroot automatiza a construção de um sistema de arquivos raiz com todas as ferramentas necessárias como busybox. Isso torna muito mais fácil do que fazê-lo com a mão.
Você pode perguntar por que essa ferramenta é necessário quando você pode compilar gcc , binutils , uClibc e todas as outras ferramentas à mão. É claro que isso é possível, mas, lidando com todas as opções de configuração e problemas de cada gcc ou binutils versão é muito demorado e desinteressante. Buildroot automatiza esse processo através do uso de Makefiles e tem uma coleção de correções para cada gcc e binutils versão para fazê-los funcionar na maioria das arquitecturas. Além disso, BuildRoot fornece uma infra-estrutura para reproduzir o processo de construção do seu kernel, cross-toolchain, e sistema de arquivos raiz incorporado. Ser capaz de reproduzir o processo de construção vai ser útil quando um componente precisa ser corrigido ou atualizado ou quando outra pessoa é suposto para assumir o projeto.
Obtenção BuildRoot Buildroot releases são feitos aproximadamente a cada 3 meses. Git acesso direto e diário instantâneos também estão disponíveis, se você quiser borda mais sangramento. Lançamentos estão disponíveis em http://buildroot.net/downloads/ . O último snapshot está sempre disponível em http://buildroot.net/downloads/snapshots/buildrootsnapshot.tar.bz2 e instantâneos anteriores também estão disponíveis no http://buildroot.net/downloads/snapshots/ . Para fazer o download BuildRoot usando Git, você pode simplesmente seguir as regras descritas no "Acessando Git" página ( http://buildroot.net/git.html ) do site BuildRoot ( http://buildroot.net ). Para os impacientes, aqui vai uma receita rápida: $ Git clone git: / / git.buildroot.net / buildroot
Usando BuildRoot Buildroot tem uma boa ferramenta de configuração semelhante à que você pode encontrar no kernel do Linux ( http://www.kernel.org/ ) ou em Busybox ( http://www.busybox.org/ ). Note que você pode (e deve) construir tudo como um usuário normal. Não há necessidade de ser root para configurar e usar BuildRoot. O primeiro passo é executar o assistente de configuração: $ Make menuconfig
para executar o configurador baseado em curses, ou $ Make xconfig
ou
$ Make gconfig
para executar o Qt ou GTK baseado configuradores. Todos estes "make" comandos precisará construir um utilitário de configuração, assim você pode precisar instalar o "desenvolvimento" pacotes para as bibliotecas relevantes utilizados pelos utilitários de configuração. Em Debian-like sistemas, o libncurses5-dev pacote é necessário usar a interface menuconfig, libqt4-dev é necessário para usar a interface xconfig, e libglib2.0-dev, libgtk2.0-dev and libglade2-dev são necessários para usar a interface gconfig. Para cada entrada do menu na ferramenta de configuração, você pode encontrar ajuda associado que descreve a finalidade da entrada. Depois que tudo estiver configurado, a ferramenta de configuração gera um .config arquivo que contém a descrição de sua configuração. Ele será usado pela Makefiles para fazer o que é necessário. Vamos lá: $ Make
Você nunca deve usar make -jN com BuildRoot: ele não suporta mais alto nível paralelo fazer. Em vez disso, use o BR2_JLEVEL opção para dizer BuildRoot para executar cada compilação pacote com make -jN . Este comando geralmente execute os seguintes passos: • •
• • • •
Baixar arquivos de origem (conforme necessário) Configurar, construir e instalar a compilação cruzada toolchain se um conjunto de ferramentas interno é usado, ou importar um toolchain se um toolchain externo é utilizado Construir / instalar pacotes alvo selecionado Construir uma imagem de kernel, se selecionado Construir uma imagem do bootloader, se selecionado Criar um sistema de arquivos raiz em formatos selecionados
Buildroot saída é armazenada em um único diretório, output/ . Este diretório contém vários subdiretórios: •
•
•
•
images/ onde todas as imagens (imagem do kernel bootloader, e as imagens do sistema de arquivos raiz) são armazenados. build/ onde todos os componentes, exceto para o toolchain compilação cruzada são construídos (isso inclui ferramentas necessárias para executar BuildRoot no host e pacotes compilados para o alvo). O build/ diretório contém um subdiretório para cada um desses componentes. staging/ que contém uma hierarquia semelhante a uma hierarquia do sistema de arquivos raiz. Este diretório contém a instalação da compilação cruzada toolchain e todos os pacotes userspace selecionados para o alvo. No entanto, este diretório não se destina a ser o sistema de arquivos raiz para o alvo: ele contém uma grande quantidade de arquivos de desenvolvimento, unstripped binários e bibliotecas que a tornam muito grandes para um sistema embarcado. Estes arquivos de desenvolvimento são usados para compilar as bibliotecas e aplicações para o destino que dependem de outras bibliotecas. target/ que contém quase o sistema de arquivos raiz para o alvo: tudo que é necessário está presente, exceto os arquivos de dispositivo em /dev/ (BuildRoot não pode criá-los porque BuildRoot não executado como root e não deseja executar como root) . Portanto, este diretório não deve ser usado em seu alvo. Em vez disso, você deve usar uma das imagens construídas no images/ diretório. Se você precisa de uma imagem extraída do sistema de
•
•
arquivos raiz para a inicialização através de NFS, em seguida, usar a imagem gerada em tarball images/ e extraí-lo como root. Em comparação com staging/ , target/ contém apenas os arquivos e bibliotecas necessários para executar os aplicativos de destino selecionado: os arquivos de desenvolvimento (cabeçalhos, etc) não estão presentes, a menos que o development files in target filesystem opção for selecionada. host/ contém a instalação de ferramentas de compilação para o host que são necessários para a correcta execução das BuildRoot, incluindo o toolchain compilação cruzada. toolchain/ contém os diretórios de construção para os diversos componentes do toolchain compilação cruzada.
Constrói off-line Se você pretende fazer uma compilação offline e só quero baixar todas as fontes que você selecionou anteriormente no configurador (menuconfig, ou xconfig gconfig), assuntos de então: $ Make fonte
Agora você pode desconectar ou copiar o conteúdo do seu dl diretório para a construção de host.
Construção de out-of-árvore Buildroot suporta a construção de árvore com uma sintaxe semelhante ao kernel Linux. Para usá-lo, adicione O
= à linha de comando make: $ Make O = / tmp / build
Ou: $ Cd / tmp / build; fazer O caminho = $ PWD-C / para / buildroot
Todos os arquivos de saída serão localizados sob /tmp/build . Ao usar out-of-árvore constrói, o BuildRoot .config ficheiros e temporárias também são armazenados no diretório de saída. Isto significa que você pode seguramente executar vários builds em paralelo com a árvore mesma fonte, desde que use diretórios de saída única. Para facilidade de uso, BuildRoot gera um wrapper Makefile no diretório de saída - Assim, após a primeira execução, você não precisa mais passar O=.. e -C .. , basta executar (no diretório de saída): $ Make
Variáveis de ambiente Buildroot também homenageia algumas variáveis de ambiente, quando eles são passados para make ou no meio ambiente: •
•
•
•
•
HOSTCXX , o host C + + compilador para usar HOSTCC , o anfitrião do compilador C para uso UCLIBC_CONFIG_FILE= , caminho para o arquivo de configuração uClibc, usado para compilar uClibc, se um conjunto de ferramentas interna está sendo construída BUSYBOX_CONFIG_FILE= , caminho para o arquivo de configuração Busybox BUILDROOT_DL_DIR para substituir o diretório que armazena BuildRoot / recupera
arquivos baixados Um exemplo que usa arquivos de configuração localizado no diretório principal e em sua $ HOME: $ Make UCLIBC_CONFIG_FILE = uClibc.config BUSYBOX_CONFIG_FILE = $ HOME / bb.config
Se você quiser usar um compilador diferente do padrão gcc ou g++ para a construção de helperbinários em seu anfitrião, em seguida, fazer $ Make HOSTCXX = g + + CABEÇA-4.3-HOSTCC = gcc-4.3-HEAD
Personalizar o sistema de arquivos gerados alvo Existem algumas maneiras de personalizar o sistema de arquivos de destino resultante: •
•
•
•
Personalizar o sistema de arquivos alvo diretamente e reconstruir a imagem. O sistema de arquivos-alvo está disponível sob output/target/ . Você pode simplesmente fazer as alterações aqui e execute make depois - o que irá reconstruir a imagem do sistema de arquivos-alvo. Este método permite que você faça alguma coisa para o sistema de arquivos de destino, mas se você decidir reconstruir completamente a sua toolchain e ferramentas, estas alterações serão perdidas. Crie seu esqueleto própria meta. Você pode começar com o esqueleto padrão disponível sob fs/skeleton e depois personalizá-lo para atender às suas necessidades. O BR2_ROOTFS_SKELETON_CUSTOM e BR2_ROOTFS_SKELETON_CUSTOM_PATH permitirá que você especifique o local de seu esqueleto personalizado. Em tempo de compilação, o conteúdo do esqueleto são copiados para a saída / target antes de qualquer instalação do pacote. Na configuração BuildRoot, você pode especificar o caminho para um script de pós-build, que é chamado depois BuildRoot constrói todo o software selecionado, mas antes que os pacotes são montados rootfs. O destino da pasta raiz é dado como o primeiro argumento para o script, e esse script pode ser usado para programas de cópia, os dados estáticos ou qualquer outro arquivo necessário para seu sistema de arquivos-alvo. Você deve, no entanto, usar esse recurso com cuidado. Sempre que você achar que um determinado pacote gera arquivos errados ou desnecessários, você deve corrigir esse pacote ao invés de trabalhar em torno dele com um script de limpeza pós-compilação. Um pacote especial, personalizar, armazenada em package/customize podem ser usados. Você pode colocar todos os arquivos que você deseja ver no sistema de arquivos raiz no objectivo final package/customize/source , e então permitir que este pacote especial no sistema de configuração.
Personalizando a configuração Busybox Busybox é muito configurável, e você pode querer personalizá-lo. Você pode seguir estes passos simples para fazer isso. Este método não é ideal, mas é simples e funciona: 1. Fazer uma compilação inicial de BuildRoot, com busybox, sem tentar personalizá-lo. 2. Invoke make busybox-menuconfig . A ferramenta de configuração aparece agradável, e você pode personalizar tudo. 3. Executar a compilação de BuildRoot novamente. Caso contrário, você pode simplesmente mudar o package/busybox/busybox.config arquivo, se você sabe as opções que pretende alterar, sem usar a ferramenta de configuração.
Se você quiser usar um arquivo de configuração existentes para busybox, então consulte a secção variáveis de ambiente .
Personalizando a configuração uClibc Assim como BusyBox , uClibc oferece uma série de opções de configuração. Eles permitem que você selecione várias funcionalidades dependendo de suas necessidades e limitações. A maneira mais fácil de modificar a configuração do uClibc é seguir estes passos: 1. Fazer uma compilação inicial de BuildRoot sem tentar personalizar uClibc. 2. Invoke make uclibc-menuconfig . O assistente de configuração agradável, semelhante ao usado no kernel do Linux ou BuildRoot, aparece. Faça as alterações de configuração conforme apropriado. 3. Copie o $(O)/toolchain/uclibc-VERSION/.config arquivo para um lugar diferente (como toolchain/uClibc/uClibc-myconfig.config , ou board/mymanufacturer/myboard/uClibc.config ) e ajustar a configuração uClibc (configuração opção BR2_UCLIBC_CONFIG ) para usar essa configuração em vez do padrão. 4. Executar a compilação de BuildRoot novamente. Caso contrário, você pode simplesmente mudar toolchain/uClibc/uClibc.config , sem correr o assistente de configuração. Se você quiser usar um arquivo de configuração existentes para uClibc, então consulte a secção variáveis de ambiente .
Personalizando a configuração do kernel Linux A configuração do kernel Linux pode ser personalizado como BusyBox e uClibc usando make linux-menuconfig . Certifique-se de ter habilitado o kernel construir no make menuconfig primeiro. Uma vez feito isso, execute make a (re) construir tudo. Se você quiser usar um arquivo de configuração existentes para Linux, então consulte a secção variáveis de ambiente .
Compreensão de como reconstruir pacotes Uma das perguntas mais comuns feitas pelos usuários BuildRoot é como reconstruir um determinado pacote ou como remover um pacote sem reconstruir tudo do zero. Remoção de um pacote está atualmente não suportada pelo BuildRoot sem reconstrução do zero. Isto é porque BuildRoot não acompanhar o que o pacote instala arquivos na output/staging e output/target diretórios. No entanto, a implementação de remoção do pacote limpa está na TODO list dos desenvolvedores BuildRoot. A maneira mais fácil reconstruir um único pacote a partir do zero é remover o diretório construir em output/build . Buildroot então re-extract, re-configurar, re-re-compilar e instalar este pacote a partir do zero. No entanto, se você não quiser reconstruir o pacote completamente do zero, uma melhor compreensão dos internals BuildRoot é necessário. Internamente, para acompanhar os passos que têm sido feitos e que há ainda muito a ser feito, BuildRoot mantém arquivos de selo (arquivos vazios que apenas dizer se essa ou aquela ação tem sido feito). O problema é que esses arquivos não são uniformemente selo chamado e manipulados pelos pacotes diferentes, por isso alguma compreensão do pacote especial é necessária.
Para pacotes contando com infra-estruturas BuildRoot pacotes (veja nesta seção para mais detalhes), os arquivos de selo são relevantes: •
•
output/build/packagename-version/.stamp_configured. Se removido, BuildRoot irá acionar a recompilação do pacote a partir da etapa de configuração (execução de ./configure ). output/build/packagename-version/.stamp_built . Se removido, BuildRoot irá acionar a recompilação do pacote da etapa de compilação (execução de make ).
Para outros pacotes, uma análise do arquivo package.mk específico é necessário. Por exemplo, o Makefile zlib costumava olhar assim (antes de ser convertido para a infra-estrutura pacote genérico): $ (ZLIB_DIR) / configurados:. $ (ZLIB_DIR) / corrigido. (Cd $ (ZLIB_DIR); rm-rf config.cache; \ [...] ) toque $ @ $ (ZLIB_DIR) / libz.a: $ (ZLIB_DIR) / configurado. $ (MAKE)-C $ (ZLIB_DIR) todos os libz.a touch-c $ @
Se você deseja acionar a reconfiguração, você precisa remover output/build/zlibversion/.configured . Se você deseja acionar apenas a recompilação, você precisa remover output/build/zlib-version/libz.a . Note-se que a maioria dos pacotes, se não todos, serão progressivamente transferidos ao longo da infra-estrutura genérica ou autotools, tornando muito mais fácil para reconstruir pacotes individuais.
Como funciona BuildRoot Como mencionado acima, BuildRoot é basicamente um conjunto de Makefiles que o download, configurar e compilar o software com as opções corretas. Ele também inclui patches para vários pacotes de software - principalmente os envolvidos na cadeia de ferramenta cross-compilação ( gcc , binutils e uClibc ). Há, basicamente, um Makefile por pacote de software, e eles são nomeados com o .mk extensão. Makefiles são divididos em três secções principais: •
•
•
toolchain (no toolchain/ diretório) contém os arquivos Makefiles e associados para
todos os softwares relacionados com o toolchain compilação cruzada: binutils , gcc , gdb , kernel-headers e uClibc . pacote (no package/ diretório) contém os arquivos Makefiles e associados para todas as ferramentas do espaço do usuário que BuildRoot pode compilar e adicionar ao sistema de arquivos raiz de destino. Há um sub-diretório por ferramenta. alvo (no target diretório) contém os arquivos Makefiles e associados para software relacionado à geração da imagem do sistema de arquivos raiz meta. Quatro tipos de sistemas de arquivos são suportados: ext2, jffs2, cramfs e squashfs. Para cada um deles há um subdiretório com os arquivos necessários. Há também um default/ diretório que contém o esqueleto do sistema de arquivos-alvo.
Cada diretório contém pelo menos dois arquivos: •
something.mk é o Makefile que downloads, configura, compila e instala o pacote de something .
•
Config.in é uma parte do arquivo de configuração ferramenta de descrição. Ele descreve as opções relacionadas com o pacote.
O Makefile principal executa as seguintes etapas (uma vez que a configuração é feita): 1. Criar todos os diretórios de saída: staging , target , build , stamps , etc no diretório de saída ( output/ por padrão, outro valor pode ser especificado usando O= ) 2. Gerar todas as metas traçadas na BASE_TARGETS variável. Quando um toolchain interna é usada, isto significa gerar a compilação cruzada toolchain. Quando um toolchain externa é usada, isto significa verificar as características do conjunto de ferramentas externas e importá-la no ambiente BuildRoot. 3. Gerar todas as metas traçadas na TARGETS variável. Esta variável é preenchida por Makefiles todos os componentes individuais ". Gerando essas metas irá desencadear a compilação dos pacotes userspace (bibliotecas, programas), o kernel, o bootloader ea geração das imagens do sistema de arquivos raiz, dependendo da configuração.
Criar o seu próprio suporte de placa Criar o seu próprio suporte de placa em BuildRoot permite que os usuários de uma plataforma de hardware específico para facilmente construir um sistema que é conhecido para o trabalho. Para isso, você precisa criar uma configuração BuildRoot normal que constrói um sistema básico para o hardware: kernel, toolchain, bootloader, sistema de arquivos e um userspace simples Busybox-only. Nenhum pacote específico deve ser selecionado: a configuração deve ser o mínimo possível, e só deve construir um sistema Busybox fundamentais de trabalho para a plataforma alvo. Pode, claro, usar as configurações mais complicadas para os seus projetos internos, mas o projeto só irá integrar BuildRoot configurações da placa básica. Isto é porque seleções de pacotes são altamente específico do aplicativo. Depois de ter uma configuração conhecida de trabalho, executar make savedefconfig . Isso irá gerar um mínimo de defconfig arquivo na raiz da árvore fonte BuildRoot. Mova este arquivo para a configs/ diretório e renomeá-lo MYBOARD_defconfig . Recomenda-se usar o máximo possível versões originais do kernel do Linux e gerenciadores de partida, e para utilizar, tanto quanto possível kernel padrão e configurações bootloader. Se eles estão incorretas para sua plataforma, nós encorajamos você a enviar correções para os projetos correspondentes a montante. No entanto, nesse meio tempo, você pode querer armazenar kernel ou bootloader configuração ou patches específicos para sua plataforma de destino. Para fazer isso, crie um diretório board/MANUFACTURER e um subdiretório board/MANUFACTURER/BOARDNAME (após a substituição, é claro, fabricante e BOARDNAME com os valores apropriados, em letras minúsculas). Você pode então armazenar seus patches e configurações nestes diretórios, e referenciá-los a partir da configuração BuildRoot principal.
Usando o gerado BuildRoot toolchain fora Você pode querer compilar, para o seu alvo, os seus próprios programas ou outros softwares que não são embalados em BuildRoot. Para fazer isso, você pode usar o toolchain que foi gerado pelo BuildRoot. O toolchain gerada pelo BuildRoot está localizado por padrão na output/host/ . A maneira mais simples para usá-lo é adicionar output/host/usr/bin/ para a variável de ambiente PATH e depois de usar ARCH-linux-gcc , ARCH-linux-objdump , ARCH-linux-ld , etc É possível mudar o local da toolchain - mas então --sysroot deve ser passado sempre que o
compilador é chamado a dizer onde as bibliotecas e arquivos de cabeçalho são. Também é possível gerar o BuildRoot toolchain em um diretório que não seja output/host usando o Build options -> Host dir opção. Isto pode ser útil se o toolchain devem ser compartilhados com outros usuários.
Usando ccache em BuildRoot ccache é um cache do compilador. Ele armazena os arquivos objeto resultante de cada processo de compilação, e é capaz de pular compilação futuro do mesmo arquivo de origem (com mesmo compilador e argumentos mesmo) usando os arquivos pré-existentes objeto. Ao fazer constrói quase idênticos a partir do zero várias vezes, ele pode muito bem acelerar o processo de construção. ccache suporte é integrado em BuildRoot. Você apenas tem que habilitar Enable compiler cache em Build options . Isso irá criar automaticamente ccache e usá-lo para cada host e compilação alvo.
O cache está localizada em $HOME/.buildroot-ccache . Ela é armazenada fora do diretório de saída BuildRoot para que ele possa ser compartilhado por constrói BuildRoot separado. Se você quer se livrar do cache, basta remover este diretório. Você pode obter estatísticas sobre o cache (seu tamanho, número de hits, misses, etc), executando make ccache-stats .
Localização de pacotes baixados Pode ser útil saber que o tarballs diferentes que são baixados pela Makefiles são todos armazenados no DL_DIR que por padrão é o dl diretório. É útil, por exemplo, se você quiser manter uma versão completa do BuildRoot que é conhecido por trabalhar com o tarballs associados. Isto permitirá que você para regenerar o toolchain eo sistema de arquivos-alvo com exatamente as mesmas versões. Se você mantém várias árvores BuildRoot, talvez seja melhor ter um local de download compartilhada. Isso pode ser acessado através da criação de um link simbólico do dl diretório para o local de download compartilhada: $ Ln-s compartilhada> baixar location> dl
Outra forma de acessar um local de download compartilhada é criar o BUILDROOT_DL_DIR variável de ambiente. Se isso for definido, então o valor da DL_DIR no projeto é substituído. A seguinte linha deve ser adicionada ao "~/.bashrc" . $ Export BUILDROOT_DL_DIR compartilhada> location> baixar
Usando um conjunto de ferramentas externas Usando um conjunto de ferramentas já existentes é útil, por diferentes razões: •
•
•
você já tem um conjunto de ferramentas que é conhecido por trabalhar para a sua CPU específica você quiser acelerar o processo de construção BuildRoot saltando a longa peça construir toolchain o recurso de geração de toolchain BuildRoot não é suficientemente flexível para você (por exemplo, se você precisa gerar um sistema com glibc, em vez de uClibc)
Buildroot suporta o uso de toolchains existentes através de um mecanismo chamado externo toolchain. O mecanismo externo toolchain está habilitado no Toolchain menu, selecionando
External toolchain no Toolchain type .
Então, você tem três soluções para usar um toolchain externo: •
•
•
Use um perfil externo predefinidos toolchain, e deixe BuildRoot download, extrair e instalar o toolchain. Buildroot já sabe sobre um toolchains CodeSourcery poucos para ARM, PowerPC, MIPS e SuperH. Basta selecionar o perfil toolchain no Toolchain com os disponíveis. Esta é definitivamente a solução mais fácil. Usar um perfil pré-definido toolchain externa, mas em vez de ter BuildRoot baixar e extrair o toolchain, você pode dizer BuildRoot onde seu toolchain já está instalado em seu sistema. Basta selecionar o perfil toolchain no Toolchain com os disponíveis, desmarque Download toolchain automatically , e preencher o Toolchain path de entrada de texto com o caminho para o cross-compilar toolchain. Use um conjunto de ferramentas totalmente personalizadas externo. Isto é particularmente útil para toolchains gerados usando Crosstool NG. Para fazer isso, selecione o Custom toolchain solução no Toolchain lista. É necessário preencher o Toolchain path , Toolchain prefix e External toolchain C library opções. Então, você tem que dizer o que o seu BuildRoot externa suporta toolchain. Se o seu toolchain externa usa a biblioteca glibc, você só tem que dizer se o seu suporta toolchain C + + ou não. Se o seu toolchain externa usa a biblioteca uClibc, então você tem que dizer se ele suporta BuildRoot largefile, IPv6, RPC, larga-char locale, programa de invocação, tópicos e C + +. No início da execução, BuildRoot vai dizer se as opções selecionadas não corresponder à configuração toolchain.
Nosso apoio externo toolchain foi testado com toolchains de CodeSourcery, toolchains gerada pelo Crosstool-NG , e toolchains gerada pelo BuildRoot si. Em geral, todos toolchains que suportam o recurso sysroot deve funcionar. Se não for, não hesite em entrar em contato com os desenvolvedores. Não apoiamos toolchains do ELDK de Denx , por duas razões: •
•
O ELDK não contém um toolchain puro (ou seja, apenas o compilador, binutils, a C e C + + bibliotecas), mas um conjunto de ferramentas que vem com um conjunto muito grande de pré-compilados bibliotecas e programas. Portanto, BuildRoot não pode importar o sysroot do toolchain, pois poderia conter centenas de megabytes de pré-compilados bibliotecas que são normalmente construídas por BuildRoot. O toolchains ELDK ter um mecanismo completamente fora do padrão personalizado para lidar com múltiplas variantes biblioteca. Em vez de usar o padrão GCC mecanismo multilib, o ELDK ARM diferentes usos links simbólicos para o compilador para diferenciar entre as variantes biblioteca (por ARM macio-float e ARM VFP), eo PowerPC ELDK compilador usa uma CROSS_COMPILE variável de ambiente. Este comportamento não-padrão dificulta o apoio ELDK em BuildRoot.
Nós também não suportam o uso da distribuição toolchain (ou seja, a biblioteca do gcc / binutils / C instalado pela sua distribuição) como o conjunto de ferramentas para criar software para o destino. Isso ocorre porque sua distribuição toolchain não é um "puro" toolchain (ou seja, apenas com o C / C + + biblioteca), por isso não podemos importá-lo corretamente no BuildRoot construir ambiente. Assim, mesmo se você está construindo um sistema para um alvo x86 ou x86_64, você tem que gerar uma compilação cruzada toolchain com BuildRoot ou Crosstool NG.
Adicionando novos pacotes BuildRoot Esta seção aborda como novos pacotes (bibliotecas userspace ou aplicações) podem ser integrados em BuildRoot. Ele também mostra como os pacotes existentes são integrados, o que é necessário para a correção de problemas ou ajuste sua configuração.
• •
•
Diretório do pacote Config.in arquivo O .mk arquivo Makefile para pacotes genéricos: tutorial Makefile para pacotes genéricos: referência Makefile para autotools baseado pacotes: tutorial Makefile para autotools baseado pacotes: de referência Makefile para CMake baseado pacotes: tutorial Makefile para CMake baseado pacotes: de referência Manual Makefile: tutorial Gettext integração e interação com pacotes • • • • • • •
•
Diretório do pacote Antes de mais nada, crie um diretório sob o package software para o seu diretório, por exemplo libfoo . Alguns pacotes foram agrupados por tema em um sub-diretório: multimedia , java , x11r7 , e games . Se o seu pacote se encaixa em uma dessas categorias, então criar o seu diretório do pacote nestes.
Config.in arquivo Em seguida, crie um arquivo chamado Config.in . Este arquivo conterá as descrições opção relacionada com a nossa libfoo software que será usado e exibido na ferramenta de configuração. Deve conter, basicamente: configuração BR2_PACKAGE_LIBFOO bool "libfoo" ajuda Este é um comentário que explica o que é libfoo. http://foosoftware.org/libfoo/
Claro, você pode adicionar outras opções para configurar as coisas em particular no seu software. Você pode olhar para exemplos em outros pacotes. A sintaxe do arquivo Config.in é o mesmo que aquele para o arquivo KConfig kernel. A documentação para esta sintaxe está disponível em http://lxr.free-electrons.com/source/Documentation/kbuild/kconfig-language.txt Finalmente, você tem que adicionar seu novo libfoo/Config.in de package/Config.in (ou em uma categoria subdiretório se você decidiu colocar o pacote em uma das categorias existentes). Os ficheiros incluídos existem classificados em ordem alfabética por categoria e não são supostamente para conter qualquer coisa, mas o nome simples do pacote. "pacote / libfoo / Config.in" fonte
O .mk arquivo Finalmente, aqui está a parte mais difícil. Crie um arquivo chamado libfoo.mk . Ele descreve como o pacote deve ser baixado, configurado, fabricados, instalados, etc Dependendo do tipo de pacote, o .mk arquivo deve ser escrito de uma maneira diferente, utilizando diferentes infra-estruturas: •
Makefiles para pacotes genéricos (não usando autotools): Estes são baseados em uma
•
•
infra-estrutura semelhante ao usado para autotools baseado em pacotes, mas requer um pouco mais trabalho do desenvolvedor. Eles especificar o que deve ser feito para a configuração, compilação, instalação e limpeza do pacote. Esta infra-estrutura deve ser utilizado para todos os pacotes que não usam o autotools como seu sistema de compilação. No futuro, outras infra-estruturas especializadas poderiam ser escritas para outros sistemas de construção. Nós cobri-los através de um tutorial e uma referência . Makefiles para autotools baseado software (autoconf, automake, etc): Nós fornecemos uma infra-estrutura dedicada para tais pacotes, pois autotools é um sistema de construção muito comum. Esta infra-estrutura deve ser utilizado para novos pacotes que dependem do autotools como seu sistema de compilação. Nós cobri-los através de um tutorial e uma referência . Manual Makefiles: Estes são atualmente obsoletos, e nenhum novo manual de Makefiles deve ser adicionada. No entanto, uma vez que ainda há muitos deles na árvore, nós mantêlos documentado em um tutorial .
Makefile para pacotes genéricos: tutorial 01: ################################################ ############# 02: # 03: # libfoo 04: # 05: ################################################ ############# 06: LIBFOO_VERSION = 1,0 07: LIBFOO_SOURCE = libfoo-$ (LIBFOO_VERSION) tar.gz. 08: LIBFOO_SITE = http://www.foosoftware.org/download 09: LIBFOO_INSTALL_STAGING = YES 10: LIBFOO_DEPENDENCIES = host-libaaa libbbb 11: 12: define LIBFOO_BUILD_CMDS 13: $ (MAKE) CC = $ (TARGET_CC) LD = $ (TARGET_LD)-C $ (@ D) todos os 14: ENDEF 15: 16: define LIBFOO_INSTALL_STAGING_CMDS 17: $ (INSTALL)-D-m 0755 $ (@ D) / libfoo.a $ (STAGING_DIR) / usr / lib / libfoo.a 18: $ (INSTALL)-D-m 0644 $ (@ D) / foo.h $ (STAGING_DIR) / usr / include / foo.h 19: $ (INSTALL)-D-m 0755 $ (@ D) / libfoo.so * $ (STAGING_DIR) / usr / lib 20: ENDEF 21: 22: define LIBFOO_INSTALL_TARGET_CMDS 23: $ (INSTALL)-D-m 0755 $ (@ D) / libfoo.so * $ (target_dir) / usr / lib 24: $ (INSTALL)-d-m 0755 $ (target_dir) / etc / foo.d 25: ENDEF 26: 27: $ (eval $ (GENTARGETS chamada, pacote, libfoo))
O Makefile começa na linha 6-8, com informações de metadados: a versão do pacote ( LIBFOO_VERSION ), o nome do tarball contendo o pacote ( LIBFOO_SOURCE ) eo local de Internet em que o tarball pode ser baixado ( LIBFOO_SITE ). Todas as variáveis devem começar com o mesmo prefixo, LIBFOO_ neste caso. Este prefixo é sempre a versão maiúscula do nome do pacote (veja abaixo para entender onde o nome do pacote é definido). Na linha 9, especificamos que este pacote quer instalar algo para o espaço de teste. Isso é muitas vezes necessário para as bibliotecas, uma vez que deve instalar arquivos de cabeçalho e arquivos de desenvolvimento outro no espaço de teste. Isso irá garantir que os comandos listados na
LIBFOO_INSTALL_STAGING_CMDS variável será executado.
Na linha 10, nós especificar a lista de dependências este pacote depende. Essas dependências são listados em termos de nomes em minúsculo pacote, que pode ser pacotes para o destino (sem o host- prefixo) ou pacotes para o host (com o host- ) prefixo). Buildroot irá garantir que todos estes pacotes são construídos e instalados antes do pacote atual inicia a sua configuração. O resto do Makefile define o que deve ser feito em diferentes etapas da compilação do pacote de configuração e instalação. LIBFOO_BUILD_CMDS diz que passos devem ser realizados para construir o pacote. LIBFOO_INSTALL_STAGING_CMDS diz que medidas devem ser executadas para instalar o pacote no espaço de preparação . LIBFOO_INSTALL_TARGET_CMDS diz que medidas devem ser executadas para instalar o pacote no espaço-alvo. Todos estes passos dependem do $(@D) variável, que contém o diretório onde o código-fonte do pacote foi extraído. Finalmente, na linha 27, chamamos o GENTARGETS que gera, de acordo com as variáveis definidas anteriormente, todo o código Makefile necessário para tornar o seu pacote de trabalho. Makefile para pacotes genéricos: referência
O GENTARGETS macro recebe três argumentos: •
•
•
O primeiro argumento é o prefixo diretório do pacote. Se o seu pacote está no package/libfoo , o prefixo de diretório é package . Se o seu pacote está no package/editors/foo , o prefixo de diretório deve ser package/editors . O segundo argumento é o nome do pacote escrito em minúscula. Ele deve corresponder ao prefixo das variáveis no .mk arquivo e deve coincidir com o nome da opção de configuração no Config.in arquivo. Por exemplo, se o nome do pacote é libfoo , então as variáveis no .mk arquivo deve começar com LIBFOO_ ea opção de configuração no Config.in arquivo deve ser BR2_PACKAGE_LIBFOO . O terceiro argumento é opcional. Ele pode ser usado para dizer se o pacote é um pacote de destino (cross-compilados para o destino) ou um pacote de host (nativamente compilados para o host). Se não for especificado, presume-se que é um pacote de destino. Veja os detalhes abaixo.
Para um determinado pacote, em um único .mk arquivo, é possível chamar GENTARGETS duas vezes, uma para criar as regras para gerar um pacote de destino e uma vez para criar as regras para gerar um pacote de host: $ (Eval $ (GENTARGETS chamada, pacote, libfoo)) $ (Eval $ (GENTARGETS chamada, pacote, libfoo, host))
Isso pode ser útil se a compilação do pacote de destino exige algumas ferramentas para ser instalado no host. Se o nome do pacote é libfoo , então o nome do pacote para o alvo também é libfoo , enquanto o nome do pacote para o host é host-libfoo . Estes nomes devem ser utilizados nas variáveis dependências de outros pacotes, se eles dependem libfoo ou host-libfoo . A chamada para o GENTARGETS macro deve estar no final do .mk arquivo, depois de todas as definições de variáveis. Para o pacote de destino, o GENTARGETS utiliza as variáveis definidas pelo arquivo mk e prefixados pelo nome do pacote minúsculo:. LIBFOO_* . Para o pacote do host, ele usa o HOST_LIBFOO_* . Para algumas variáveis, se o HOST_LIBFOO_ variável prefixado não existe, a infra-estrutura pacote usa a variável correspondente prefixado por LIBFOO_ . Isto é feito para as variáveis que possam ter o mesmo valor para ambos alvo e pacotes de host. Veja os detalhes abaixo. A lista de variáveis que podem ser definidos em um .mk arquivo para dar informações de
metadados é (assumindo que o nome do pacote é libfoo ): •
•
•
•
•
•
•
•
LIBFOO_VERSION , obrigatória, deve conter a versão do pacote. Note que se HOST_LIBFOO_VERSION não existe, é assumido como sendo o mesmo que LIBFOO_VERSION . Também pode ser um Subversion ou Git sucursal ou tag, para pacotes que são buscadas diretamente de seu sistema de controle de revisão. Exemplo: LIBFOO_VERSION = 0.1.2 LIBFOO_SOURCE pode conter o nome do tarball do pacote. Se HOST_LIBFOO_SOURCE não é especificado, o padrão é LIBFOO_VERSION . Se nenhum for especificado, então o valor é assumido como sendo packagename-$(LIBFOO_VERSION).tar.gz . Exemplo: LIBFOO_SOURCE = foobar-$(LIBFOO_VERSION).tar.bz2 LIBFOO_PATCH pode conter o nome de um patch, que será baixado a partir do mesmo local do tarball indicado no LIBFOO_SOURCE . Se HOST_LIBFOO_PATCH não é especificado, o padrão é LIBFOO_PATCH . Observe também que um outro mecanismo está disponível para corrigir um pacote: todos os arquivos da forma packagenamepackageversion-description.patch presente no diretório do pacote dentro BuildRoot será aplicada para o pacote após a extração. LIBFOO_SITE pode conter a localização do pacote de Internet. Ela pode ser a localização de HTTP ou FTP de um tarball, ou o URL de um repositório Git ou Subversion (veja LIBFOO_SITE_METHOD abaixo). Se HOST_LIBFOO_SITE não é especificado, o padrão é LIBFOO_SITE . Se nenhum for especificado, então o local é considerado http://$$ (BR2_SOURCEFORGE_MIRROR).dl.sourceforge.net/sourceforge/packa gename . Exemplos: LIBFOO_SITE=http://www.libfoosoftware.org/libfoo LIBFOO_SITE=http://svn.xiph.org/trunk/Tremor/ LIBFOO_SITE_METHOD pode conter o método para buscar o código fonte do pacote. Ela pode ser wget (para normal FTP / HTTP downloads de tarballs), svn , git ou bzr . Quando não especificado, é adivinhado a partir do URL dado em LIBFOO_SITE : svn:// , git:// e bzr:// URLs irá utilizar o svn , git e bzr métodos, respectivamente. Todos os outros tipos de URL irá usar o wget método. Assim, por exemplo, no caso de um pacote cujo código fonte está disponível através do repositório no Subversion HTTP, deve-se especifique LIBFOO_SITE_METHOD=svn . Para svn e git métodos, o que faz é BuildRoot um checkout / clone do repositório que é então tarballed e armazenados no cache de download. Constrói seguinte não checkout / clone de novo, mas vai usar o tarball diretamente. Quando HOST_LIBFOO_SITE_METHOD não for especificado, o padrão é o valor de LIBFOO_SITE_METHOD . Veja package/multimedia/tremor/ para um exemplo. LIBFOO_DEPENDENCIES lista as dependências (em termos de nome do pacote) que são necessários para o pacote alvo atual para compilar. Essas dependências são garantidos para ser compilado e instalado antes da configuração do pacote actual começa. De maneira semelhante, HOST_LIBFOO_DEPENDENCIES listas a dependência para o pacote do host atual. LIBFOO_INSTALL_STAGING pode ser configurada para YES ou NO (padrão). Se definido como YES , então os comandos no LIBFOO_INSTALL_STAGING_CMDS variáveis são executadas para instalar o pacote para o diretório teste. LIBFOO_INSTALL_TARGET pode ser definida como YES (default) ou NO . Se definido como YES , então os comandos no LIBFOO_INSTALL_TARGET_CMDS variáveis são executadas para instalar o pacote para o diretório de destino.
A maneira recomendada para definir essas variáveis é usar a seguinte sintaxe: LIBFOO_VERSION = 2,32
Agora, as variáveis que definem o que deve ser realizado em diferentes etapas do processo de construção. •
•
•
•
•
•
•
•
LIBFOO_CONFIGURE_CMDS , usado para listar as ações a serem executadas para configurar o pacote antes de sua compilação LIBFOO_BUILD_CMDS , usado para listar as ações a serem executadas para compilar o pacote HOST_LIBFOO_INSTALL_CMDS , usado para listar as ações a serem executadas para instalar o pacote, quando o pacote é um pacote de host. O pacote deve instalar seus arquivos para o diretório dado por $(HOST_DIR) . Todos os arquivos, incluindo arquivos de desenvolvimento tais como cabeçalhos devem ser instalados, uma vez que outros pacotes podem ser compilados, em cima do pacote. LIBFOO_INSTALL_TARGET_CMDS , usado para listar as ações a serem executadas para instalar o pacote para o diretório de destino, quando o pacote é um pacote de destino. O pacote deve instalar seus arquivos para o diretório dado por $(TARGET_DIR) . Apenas os arquivos necessários para a documentação e execução do pacote deve ser instalado. Arquivos de cabeçalho não deve ser instalado, eles serão copiados para o alvo, se a development files in target filesystem opção for selecionada. LIBFOO_INSTALL_STAGING_CMDS , usado para listar as ações a serem executadas para instalar o pacote para o diretório provisório, quando o pacote é um pacote de destino. O pacote deve instalar seus arquivos para o diretório dado por $(STAGING_DIR) . Todos os arquivos de desenvolvimento deve ser instalado, pois eles podem ser necessários para compilar outros pacotes. LIBFOO_CLEAN_CMDS , usado para listar as ações a executar para limpar o diretório de compilação do pacote. LIBFOO_UNINSTALL_TARGET_CMDS , usado para listar as ações para desinstalar o pacote do alvo diretório $(TARGET_DIR) LIBFOO_UNINSTALL_STAGING_CMDS , usado para listar as ações para desinstalar o pacote do teste diretório $(STAGING_DIR) .
A maneira preferida para definir essas variáveis é: definir LIBFOO_CONFIGURE_CMDS acção 1 acção 2 acção 3 ENDEF
Nas definições de ação, você pode usar as seguintes variáveis: •
•
•
•
$(@D) , que contém o diretório em que o código fonte do pacote foi descompactado. $(TARGET_CC) , $(TARGET_LD) , etc para obter o alvo compilação cruzada utilitários $(TARGET_CROSS) para obter o prefixo de compilação cruzada toolchain Claro que o $(HOST_DIR) , $(STAGING_DIR) e $(TARGET_DIR) variáveis para instalar os pacotes corretamente.
O último recurso da infra-estrutura genérica é a capacidade de adicionar os ganchos. Estes definem novas acções a realizar, após as etapas existentes. A maioria dos ganchos não são muito úteis para os pacotes genéricos, desde o .mk arquivo já tem total controle sobre as ações realizadas em cada etapa da construção do pacote. Os ganchos são mais úteis para pacotes usando a infra-estrutura autotools descrito abaixo. No entanto, uma vez que são fornecidas pela infra-estrutura genérica, que estão documentadas aqui. A exceção é LIBFOO_POST_PATCH_HOOKS . Remendar o pacote não é definido pelo usuário, de modo LIBFOO_POST_PATCH_HOOKS será userful para pacotes genéricos.
Os pontos de gancho a seguir estão disponíveis: •
•
•
•
•
•
•
LIBFOO_POST_PATCH_HOOKS LIBFOO_PRE_CONFIGURE_HOOKS LIBFOO_POST_CONFIGURE_HOOKS LIBFOO_POST_BUILD_HOOKS LIBFOO_POST_INSTALL_HOOKS (para pacotes de host somente) LIBFOO_POST_INSTALL_STAGING_HOOKS (para pacotes único alvo) LIBFOO_POST_INSTALL_TARGET_HOOKS (para pacotes único alvo)
Essas variáveis são as listas de nomes de variáveis contendo ações a serem realizadas neste momento gancho. Isto permite que vários ganchos para ser registrado em um ponto de gancho dado. Aqui está um exemplo: definir LIBFOO_POST_PATCH_FIXUP action1 action2 ENDEF LIBFOO_POST_PATCH_HOOKS + = LIBFOO_POST_PATCH_FIXUP
Makefile para autotools baseado pacotes: tutorial
Primeiro, vamos ver como escrever um .mk ficheiro para um pacote autotools-based, com um exemplo: 01: ################################################ ############# 02: # 03: # libfoo 04: # 05: ################################################ ############# 06: LIBFOO_VERSION = 1,0 07: LIBFOO_SOURCE = libfoo-$ (LIBFOO_VERSION) tar.gz. 08: LIBFOO_SITE = http://www.foosoftware.org/download 09: LIBFOO_INSTALL_STAGING = YES 10: LIBFOO_INSTALL_TARGET = YES 11: LIBFOO_CONF_OPT = - enable-shared 12: LIBFOO_DEPENDENCIES = libglib2 host-pkg-config 13: 14: $ (eval $ (AUTOTARGETS chamada, pacote, libfoo))
Na linha 6, nós declaramos a versão do pacote. Na linha 7 e 8, nós declaramos o nome do tarball e da localização do tarball na web. Buildroot fará automaticamente o download do tarball a partir desta localização. Na linha 9, dizemos BuildRoot para instalar o pacote para o diretório teste. O diretório provisório, localizado na output/staging/ é o diretório onde todos os pacotes estão instalados, incluindo arquivos de seu desenvolvimento, etc Por padrão, os pacotes não são instalados no diretório temporário, pois normalmente, apenas as bibliotecas precisam ser instalados no encenação diretório: arquivos de seu desenvolvimento são necessários para compilar outras bibliotecas ou aplicativos, dependendo deles. Também por padrão, quando a instalação de teste for ativado, os pacotes são instalados neste local usando o make install comando. Na linha 10, dizemos BuildRoot para também instalar o pacote para o diretório de destino. Este diretório contém o que se tornará o sistema de arquivos raiz em execução no alvo. Normalmente, tentamos não instalar arquivos de cabeçalho e instalar versões despojado do binário. Por padrão, instalação de destino é ativado, assim, de facto, esta linha não é estritamente necessário. Também
por padrão, os pacotes são instalados neste local usando o make install comando. Na linha 11, dizemos BuildRoot passar uma opção de configuração personalizada, que será passado para o ./configure script antes de configurar e construir o pacote. Na linha 12, nós declaramos nossas dependências, de modo que eles são construídos antes do processo de construção do nosso pacote começa. Finalmente, na linha linha 14, nós invocamos o AUTOTARGETS macro que gera todas as regras Makefile que realmente permite que o pacote a ser construído. Makefile para pacotes autotools: referência
A macro principal da infra-estrutura pacote autotools é AUTOTARGETS . Ele tem o mesmo número de argumentos eo semântico mesmo que o GENTARGETS macro, que é o principal macro da infraestrutura pacote genérico. Para pacotes autotools, a capacidade de ter os pacotes-alvo e de acolhimento também está disponível (e na verdade é amplamente utilizado). Assim como a infra-estrutura genérica, a infra-estrutura autotools funciona através da definição de uma série de variáveis antes de chamar o AUTOTARGETS macro. Primeiro, todas as variáveis do pacote de metadados informações que existem na infra-estrutura genérica também existem no autotools A poucas variáveis adicionais, específicas para a infra-estrutura autotools, também pode ser definida. Muitos deles só são úteis em casos muito específicos, pacotes típicos, portanto, usar apenas alguns deles. •
•
•
•
•
•
•
•
•
•
LIBFOO_SUBDIR pode conter o nome de um subdiretório dentro do pacote que contém o script configure. Isso é útil se, por exemplo, o script configure principal não está na raiz da árvore extraída pelo tarball. Se HOST_LIBFOO_SUBDIR não é especificado, o padrão é LIBFOO_SUBDIR . LIBFOO_CONF_ENV , para especificar variáveis de ambiente adicionais para passar para o script configure. Por padrão, o vazio. LIBFOO_CONF_OPT , para especificar opções adicionais do configure para passar para o script configure. Por padrão, o vazio. LIBFOO_MAKE , para especificar um suplente make de comando. Isto é tipicamente útil quando paralelo fazer é habilitado na configuração (usando BR2_JLEVEL ), mas que esse recurso deve ser desativado para o determinado pacote, por um motivo ou outro. Por padrão, definido como $(MAKE) . Se a construção paralela não é suportada pelo pacote, então ele deve ser definido como LIBFOO_MAKE=$(MAKE1) . LIBFOO_MAKE_ENV , para especificar variáveis de ambiente adicionais para passar a fazer na etapa de compilação. Estes são passadas antes do make de comando. Por padrão, o vazio. LIBFOO_MAKE_OPT , para especificar variáveis adicionais para passar a fazer na etapa de compilação. Estes são passados após a make comando. Por padrão, o vazio. LIBFOO_AUTORECONF , diz se o pacote deve ser autoreconfigured ou não (ou seja, se o script configure e arquivos Makefile.in deve ser re-gerado pelo re-executar autoconf, automake, libtool, etc.) Os valores válidos são YES e NO . Por padrão, o valor é NO LIBFOO_AUTORECONF_OPT para especificar opções adicionais passados para o programa autoreconf se LIBFOO_AUTORECONF=YES . Por padrão, o vazio. LIBFOO_LIBTOOL_PATCH diz se o patch para corrigir BuildRoot libtool compilação cruzada questões devem ser aplicados ou não. Os valores válidos são YES e NO . Por padrão, o valor é YES LIBFOO_INSTALL_STAGING_OPT contém opções de make usado para instalar o pacote para o diretório provisório. Por padrão, o valor é DESTDIR=$$(STAGING_DIR)
•
•
•
•
install , o que é correto para a maioria dos pacotes autotools. Ainda é possível substituílo. LIBFOO_INSTALL_TARGET_OPT contém opções de make usado para instalar o pacote para o diretório de destino. Por padrão, o valor é DESTDIR=$$(TARGET_DIR) install . O valor padrão é correto para a maioria dos pacotes autotools, mas ainda é possível substituí-lo se necessário. LIBFOO_CLEAN_OPT contém opções de make usado para limpar o pacote. Por padrão, o valor é clean . LIBFOO_UNINSTALL_STAGING_OPT , contém opções de make usado para desinstalar o pacote do diretório provisório. Por padrão, o valor é DESTDIR=$$(STAGING_DIR) uninstall . LIBFOO_UNINSTALL_TARGET_OPT , contém opções de make usado para desinstalar o pacote do diretório de destino. Por padrão, o valor é DESTDIR=$$(TARGET_DIR) uninstall .
Com a infra-estrutura autotools, todos os passos necessários para construir e instalar os pacotes já estão definidos, e eles geralmente funcionam bem para a maioria dos autotools pacotes baseados. No entanto, quando necessário, ainda é possível personalizar o que é feito em qualquer passo particular: •
•
Pela adição de um gancho de pós-operatório (após o patch extraia, configurar, construir ou instalar). Consulte a documentação de referência da infra-estrutura genérica para mais detalhes. , Substituindo um dos passos. Por exemplo, mesmo que a infra-estrutura autotools é usado, se o pacote .mk arquivo define seus próprios LIBFOO_CONFIGURE_CMDS variável, que será usado em vez do padrão autotools um. No entanto, usando este método deve ser restrito a casos muito específicos. Não usá-la no caso geral.
Makefile para CMake baseado pacotes: tutorial
Primeiro, vamos ver como escrever um .mk ficheiro de um pacote baseado em CMake, com um exemplo: 01: ################################################ ############# 02: # 03: # libfoo 04: # 05: ################################################ ############# 06: LIBFOO_VERSION = 1,0 07: LIBFOO_SOURCE = libfoo-$ (LIBFOO_VERSION) tar.gz. 08: LIBFOO_SITE = http://www.foosoftware.org/download 09: LIBFOO_INSTALL_STAGING = YES 10: LIBFOO_INSTALL_TARGET = YES 11: LIBFOO_CONF_OPT =-DBUILD_DEMOS = ON 12: LIBFOO_DEPENDENCIES = libglib2 host-pkg-config 13: 14: $ (eval $ (CMAKETARGETS chamada, pacote, libfoo))
Na linha 6, nós declaramos a versão do pacote. Na linha 7 e 8, nós declaramos o nome do tarball e da localização do tarball na web. Buildroot fará automaticamente o download do tarball a partir desta localização. Na linha 9, dizemos BuildRoot para instalar o pacote para o diretório teste. O diretório provisório, localizado na output/staging/ é o diretório onde todos os pacotes estão instalados, incluindo arquivos de seu desenvolvimento, etc Por padrão, os pacotes não são instalados no diretório temporário, pois normalmente, apenas as bibliotecas precisam ser instalados no encenação diretório:
arquivos de seu desenvolvimento são necessários para compilar outras bibliotecas ou aplicativos, dependendo deles. Também por padrão, quando a instalação de teste for ativado, os pacotes são instalados neste local usando o make install comando. Na linha 10, dizemos BuildRoot para também instalar o pacote para o diretório de destino. Este diretório contém o que se tornará o sistema de arquivos raiz em execução no alvo. Normalmente, tentamos não instalar arquivos de cabeçalho e instalar versões despojado do binário. Por padrão, instalação de destino é ativado, assim, de facto, esta linha não é estritamente necessário. Também por padrão, os pacotes são instalados neste local usando o make install comando. Na linha 11, dizemos BuildRoot passar as opções personalizadas para CMake quando é configurar o pacote. Na linha 12, nós declaramos nossas dependências, de modo que eles são construídos antes do processo de construção do nosso pacote começa. Finalmente, na linha linha 14, nós invocamos o CMAKETARGETS macro que gera todas as regras Makefile que realmente permite que o pacote a ser construído. Makefile para pacotes CMake: referência
A macro principal da infra-estrutura pacote CMake é CMAKETARGETS . Ele tem o mesmo número de argumentos eo semântico mesmo que o GENTARGETS macro, que é o principal macro da infraestrutura pacote genérico. Para pacotes CMake, a capacidade de ter os pacotes-alvo e de acolhimento também está disponível. Assim como a infra-estrutura genérica, a infra-estrutura CMake funciona através da definição de uma série de variáveis antes de chamar o CMAKETARGETS macro. Primeiro, todas as variáveis do pacote de metadados informações que existem na infra-estrutura genérica também existem no CMake A poucas variáveis adicionais, específicas para a infra-estrutura CMake, também pode ser definida. Muitos deles só são úteis em casos muito específicos, pacotes típicos, portanto, usar apenas alguns deles. •
•
•
•
•
•
•
LIBFOO_SUBDIR pode conter o nome de um subdiretório dentro do pacote que contém o arquivo CMakeLists.txt principal. Isso é útil se, por exemplo, o arquivo CMakeLists.txt principal não está na raiz da árvore extraída pelo tarball. Se HOST_LIBFOO_SUBDIR não é especificado, o padrão é LIBFOO_SUBDIR . LIBFOO_CONF_ENV , para especificar variáveis de ambiente adicionais para passar para CMake. Por padrão, o vazio. LIBFOO_CONF_OPT , para especificar opções adicionais do configure para passar para CMake. Por padrão, o vazio. LIBFOO_MAKE , para especificar um suplente make de comando. Isto é tipicamente útil quando paralelo fazer é habilitado na configuração (usando BR2_JLEVEL ), mas que esse recurso deve ser desativado para o determinado pacote, por um motivo ou outro. Por padrão, definido como $(MAKE) . Se a construção paralela não é suportada pelo pacote, então ele deve ser definido como LIBFOO_MAKE=$(MAKE1) . LIBFOO_MAKE_ENV , para especificar variáveis de ambiente adicionais para passar a fazer na etapa de compilação. Estes são passadas antes do make de comando. Por padrão, o vazio. LIBFOO_MAKE_OPT , para especificar variáveis adicionais para passar a fazer na etapa de compilação. Estes são passados após a make comando. Por padrão, o vazio. LIBFOO_INSTALL_STAGING_OPT contém opções de make usado para instalar o pacote para o diretório provisório. Por padrão, o valor é DESTDIR=$$(STAGING_DIR) install , o que é correto para a maioria dos pacotes CMake. Ainda é possível substituí-lo.
•
•
LIBFOO_INSTALL_TARGET_OPT contém opções de make usado para instalar o pacote para o diretório de destino. Por padrão, o valor é DESTDIR=$$(TARGET_DIR) install . O valor padrão é correto para a maioria dos pacotes CMake, mas ainda é possível substituí-lo se necessário. LIBFOO_CLEAN_OPT contém opções de make usado para limpar o pacote. Por padrão, o valor é clean .
Com a infra-estrutura CMake, todos os passos necessários para construir e instalar os pacotes já estão definidos, e eles geralmente funcionam bem para a maioria dos pacotes baseados CMake. No entanto, quando necessário, ainda é possível personalizar o que é feito em qualquer passo particular: •
•
Pela adição de um gancho de pós-operatório (após o patch extraia, configurar, construir ou instalar). Consulte a documentação de referência da infra-estrutura genérica para mais detalhes. , Substituindo um dos passos. Por exemplo, mesmo que a infra-estrutura CMake é usado, se o pacote .mk arquivo define seus próprios LIBFOO_CONFIGURE_CMDS variável, que será usado em vez do padrão CMake um. No entanto, usando este método deve ser restrito a casos muito específicos. Não usá-la no caso geral.
Manual Makefile: tutorial NOTA: novo manual de makefiles não deve ser criado, e manual de makefiles existentes devem ser convertidos tanto para o genérico, autotools ou infra-estrutura cmake. Esta seção é apenas mantido para documentar o manual de makefiles existentes e para ajudar a entender como eles funcionam. 01: ################################################ ############# 02: # 03: # libfoo 04: # 05: ################################################ ############# 06: LIBFOO_VERSION: = 1,0 07: LIBFOO_SOURCE:. = Libfoo-$ (LIBFOO_VERSION) tar.gz 08: LIBFOO_SITE: = http://www.foosoftware.org/downloads 09: LIBFOO_DIR: = $ (BUILD_DIR) / foo-$ (foo_versão) 10: LIBFOO_BINARY: = foo 11: LIBFOO_TARGET_BINARY: = usr / bin / foo 12: 13: $ (DL_DIR) / $ (LIBFOO_SOURCE): 14: $ (DOWNLOAD chamada, $ (LIBFOO_SITE), $ (LIBFOO_SOURCE)) 15: 16: $ (LIBFOO_DIR) / fonte:. $ (DL_DIR) / $ (LIBFOO_SOURCE) 17: $ (zcat) $ (DL_DIR) / $ (LIBFOO_SOURCE) | tar-C $ (BUILD_DIR) $ (TAR_OPTIONS) 18: touch $ @ 19: 20:. $ (LIBFOO_DIR) / configurado: $ (LIBFOO_DIR) / fonte. 21: (cd $ (LIBFOO_DIR); rm-rf config.cache; \ 22: $ (TARGET_CONFIGURE_OPTS) \ 23: $ (TARGET_CONFIGURE_ARGS) \ 24:. / Configure \ 25: - target = $ (GNU_TARGET_NAME) \ 26: - host = $ (GNU_TARGET_NAME) \ 27: - build = $ (GNU_HOST_NAME) \ 28: - prefix = / usr \ 29: - sysconfdir = / etc \ 30:) 31: touch $ @ 32:
33: $ (LIBFOO_DIR) / $ (LIBFOO_BINARY): $ (LIBFOO_DIR) / configurado. 34: $ (MAKE) CC = $ (TARGET_CC)-C $ (LIBFOO_DIR) 35: 36: $ (target_dir) / $ (LIBFOO_TARGET_BINARY): $ (LIBFOO_DIR) / $ (LIBFOO_BINARY) 37: $ (MAKE) DESTDIR = $ (target_dir)-C $ (LIBFOO_DIR) install-strip 38: rm-rf $ (target_dir) / usr / man 39: 40: libfoo: ncurses uClibc $ (target_dir) / $ (LIBFOO_TARGET_BINARY) 41: 42: libfoo-source: $ (DL_DIR) / $ (LIBFOO_SOURCE) 43: 44: libfoo-clean: 45: $ (MAKE) prefix = $ (target_dir) / usr-C $ (LIBFOO_DIR) desinstalar 46: - $ (MAKE)-C $ (LIBFOO_DIR) limpa 47: 48: libfoo-dirclean: 49: rm-rf $ (LIBFOO_DIR) 50: 51: ################################################ ############# 52: # 53: # opções de Topo Makefile 54: # 55: ################################################ ############# 56: ifeq ($ (BR2_PACKAGE_LIBFOO), y) 57: METAS + = libfoo 58: endif
Em primeiro lugar, este exemplo Makefile trabalha para um pacote que inclui um binário executável único. Para outros softwares, como bibliotecas ou coisas mais complexas com múltiplos binários, deve ser adaptado. Para exemplos olhar para o outro *.mk arquivos no package diretório. Nas linhas 11/06 , um par de variáveis úteis são definidos: •
•
•
•
•
•
LIBFOO_VERSION : A versão do libfoo que deve ser baixado. LIBFOO_SOURCE : O nome do tarball de libfoo no site de download ou site FTP. Como você pode ver LIBFOO_VERSION é usado. LIBFOO_SITE : O site HTTP ou FTP a partir do qual libfoo arquivo é baixado. Ele deve incluir o caminho completo para o diretório onde LIBFOO_SOURCE pode ser encontrado. LIBFOO_DIR : O diretório no qual o software será configurado e compilado. Basicamente, é um subdiretório do BUILD_DIR que é criado em cima de descompressão do tarball. LIBFOO_BINARY : nome do binário do Software. Como disse anteriormente, este é um exemplo para um pacote com um único binário. LIBFOO_TARGET_BINARY : O caminho completo do binário dentro do sistema de arquivos-alvo.
Linhas 13-14 definir um alvo que faz o download do tarball do site remoto para o diretório de download ( DL_DIR ). Linhas 16-18 definir um destino e as regras associadas que descompactar o tarball baixado. Como você pode ver, essa meta depende do arquivo de tarball de modo que a meta anterior (linhas 13-14 ) é chamado antes de executar as regras do alvo atual. Uncompressing é seguido por tocar em um arquivo oculto para marcar o software como tendo sido descomprimido. Este truque é usado em todos os lugares em um Makefile BuildRoot para dividir as etapas (download, descompacte, configure, compile, install) e ainda ter dependências corretas. Linhas 20-31 definir um destino e as regras associadas que configurar o software. Depende da meta anterior (o oculto .source file) de modo que temos a certeza de que o software foi descompactado. , A fim de configurar o pacote, que basicamente funciona o conhecido
./configure script. Como podemos fazer compilação cruzada, target , host e build argumentos são dadas. O prefixo também está definido para /usr , não porque o software será instalado em /usr no sistema host, mas porque o software será instalado em /usr no sistema de arquivos-alvo. Finalmente ele cria um .configured arquivo para marcar o software como configurado.
Linhas 33-34 definir um destino e uma regra que compilar o software. Esta meta será criar o arquivo binário no diretório de compilação e depende do software que está sendo já está configurado (daí a referência ao .configured arquivo). Basicamente, ela executa make dentro do diretório de origem. Linhas 36-38 definir um destino e as regras associadas que instalar o software dentro do sistema de arquivos-alvo. Eles dependem do arquivo binário no diretório de origem para garantir que o software foi compilado. Eles usam a install-strip alvo do software Makefile passando um DESTDIR argumento para que o Makefile não tenta instalar o software no host /usr , mas sim no alvo /usr . Após a instalação, o /usr/man diretório dentro do sistema de arquivos-alvo é removido para economizar espaço. Linha 40 define o alvo principal do software - o que acabará por ser usado pelo nível superior Makefile para fazer o download, compilar e, em seguida, instalar este pacote. Esta meta deve antes de tudo depende de todas as dependências necessárias do software (no nosso exemplo uClibc, e ncurses) e também dependem do binário final. Esta dependência última vai chamar todas as dependências anterior na ordem correta. Linha 42 define um alvo simples que só faz o download do código fonte. Isto não é usado durante a operação normal de BuildRoot, mas é necessário se você pretende baixar todas as fontes necessárias a uma vez para construir mais tarde offline. Note que se você adicionar um novo pacote, proporcionando uma libfoo-source alvo é obrigatória para suporte a usuários que desejam fazer offline-constrói. Além disso, facilita a verificação se todas as fontes de pacotes são para download. Linhas 44-46 definir um alvo fácil de limpar o software construir chamando o Makefile com as opções apropriadas. O -clean alvo deve executar make clean em US $ (BUILD_DIR) / pacote-versão e deve desinstalar todos os arquivos do pacote de US $ (STAGING_DIR) e de $ (target_dir). Linhas 48-49 definir um alvo fácil de remover completamente o diretório no qual o software foi descompactado, configurado e compilado. O -dirclean alvo deve completamente rm $ (BUILD_DIR) / pacote-versão. Linhas 51-58 adicionar o alvo libfoo à lista de metas a serem compilados por BuildRoot, primeiro verificar se a opção de configuração para este pacote foi ativado usando a ferramenta de configuração. Se assim for, então "subscreve" este pacote para ser compilado, adicionando o pacote para a variável de metas globais. O nome adicionado ao METAS variável global é o nome do alvo este pacote, tal como definido na linha 40 , que é usado por BuildRoot fazer o download, compilar e então instalar este pacote.
Gettext integração e interação com pacotes Muitos pacotes que a internacionalização apoio usar a biblioteca gettext. Dependências para esta biblioteca é bastante complicado e, portanto, merece uma explicação. O uClibc biblioteca C não implementa a funcionalidade gettext, portanto, com esta biblioteca C, uma gettext separado deve ser compilado. Por outro lado, a biblioteca glibc C se integra a sua própria gettext, e neste caso, a biblioteca gettext separados não deve ser compilado, porque cria vários tipos de falhas de construção.
Além disso, alguns pacotes (como libglib2) exigem gettext incondicionalmente, enquanto outros pacotes (aqueles que apóiam --disable-nls em geral) só exigem gettext quando o suporte local é ativado. Portanto, BuildRoot define duas opções de configuração: •
•
BR2_NEEDS_GETTEXT , o que é verdade, logo que o conjunto de ferramentas não fornece a sua implementação gettext própria BR2_NEEDS_GETTEXT_IF_LOCALE , o que é verdade se o toolchain não fornece a sua implementação gettext própria e se o suporte local é ativado
Portanto, pacotes que precisam incondicionalmente gettext deve: 1. Use select BR2_PACKAGE_GETTEXT if BR2_NEEDS_GETTEXT e, possivelmente, select BR2_PACKAGE_LIBINTL if BR2_NEEDS_GETTEXT , se libintl também é necessário 2. Use $(if $(BR2_NEEDS_GETTEXT),gettext) no pacote de DEPENDENCIES variável Pacotes que precisam gettext apenas quando o suporte local é habilitado deve: 1. Use select BR2_PACKAGE_GETTEXT if BR2_NEEDS_GETTEXT_IF_LOCALE e, possivelmente, select BR2_PACKAGE_LIBINTL if BR2_NEEDS_GETTEXT_IF_LOCALE , se libintl também é necessário 2. Use $(if $(BR2_NEEDS_GETTEXT_IF_LOCALE),gettext) no pacote de DEPENDENCIES variável
Conclusão Como você pode ver, acrescentando um pacote de software para BuildRoot é simplesmente uma questão de escrever um Makefile usando um exemplo existente e modificá-lo de acordo com o processo de compilação exigidos pelo pacote. Se você pacote de software que podem ser úteis para outras pessoas, não se esqueça de enviar um patch para os desenvolvedores BuildRoot!
Perguntas mais frequentes •
•
O boot trava após Starting network... module-init-tools não consegue construir com cannot find -lc
O boot trava após Starting network... Se o processo de inicialização parece travar após as seguintes mensagens (mensagens não necessarly exatamente similar, dependendo da lista de pacotes selecionados): Liberando memória init: 3972K Inicializando gerador de números aleatórios ... feito. Começando rede ... Começando dropbear sshd: geração de chaves rsa ... gerando chave dsa ...
OK
então isso significa que seu sistema está rodando, mas não iniciar um shell no console serial. A fim de ter o sistema de iniciar uma shell no seu console serial, você tem que ir na BuildRoot configuração, Target options , permitir Generic serial port config , e selecione a porta serial e velocidade que você gostaria de usar para o shell. Isto irá ajustar automaticamente o /etc/inittab arquivo do sistema gerada de modo que um shell inicia-se na porta serial correta.
module-init-tools não consegue construir com cannot find -lc Se a compilação do module-init-tools para o host falha com: / Usr / bin / ld: cannot find-lc
então provavelmente você está executando uma distribuição Fedora (ou similar), e você deve instalar o glibc-static pacote. Isso ocorre porque o module-init-tools processo de construção quer ligar estaticamente com a biblioteca C.
Recursos Para saber mais sobre BuildRoot você pode visitar estes sites: • •
http://www.uclibc.org/ http://www.busybox.net/
