Você está na página 1de 24

Buildroot

Buildroot uso e documentao por Thomas Petazzoni. Contribuies de Karsten Kruse, Ludd Ned, Herren Martin e outros. Sobre BuildRoot Obteno BuildRoot Usando BuildRoot Personalizar o sistema de arquivos gerados alvo Personalizando a configurao Busybox Personalizando a configurao uClibc Personalizando a configurao do kernel Linux Compreenso de como reconstruir pacotes Como funciona BuildRoot Usando o uClibc BuildRoot fora toolchain Use um conjunto de ferramentas externas Usando ccache em BuildRoot Localizao de pacotes baixados Adicionando novos pacotes BuildRoot Criar o seu prprio suporte de placa Perguntas mais frequentes Recursos

Sobre BuildRoot
Buildroot um conjunto de Makefiles e patches que permite que voc facilmente gerar uma compilao 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 opes, de forma independente. Buildroot til principalmente para pessoas que trabalham com sistemas embarcados. Sistemas embarcados, muitas vezes usam processadores que no so os processadores x86 regulares todos esto acostumados a ter em seu PC. Podem ser processadores PowerPC, processadores MIPS, processadores ARM, etc Uma compilao toolchain o conjunto de ferramentas que permite que voc compilar o cdigo para o seu sistema. Ele consiste de um compilador (no nosso caso, gcc ), utils binrios como assembler e linker (no nosso caso, binutils ) e uma biblioteca C padro (por exemplo Libc GNU , uClibc ou dietlibc ). O sistema instalado na sua estao de desenvolvimento, certamente j tem uma compilao toolchain que voc pode usar para compilar uma aplicao que roda em seu sistema. Se voc estiver usando um PC, suas corridas compilao toolchain em um processador x86 e gera cdigo para um processador x86. Na maioria dos sistemas Linux, a compilao toolchain usa o GNU libc (glibc) como a biblioteca C padro. Esta compilao toolchain chamado de "compilao anfitrio toolchain". A mquina em que ele est sendo executado, e no qual voc est trabalhando, chamado de "sistema host". A compilao toolchain fornecido por sua distribuio, e BuildRoot no tem nada a ver com isso (que no us-lo para construir um ferramentas de compilao cruzada toolchain e outros que so executados na mquina de desenvolvimento). Como dito acima, a compilao toolchain que vem com o sistema rodando e gera o cdigo para o processador no seu sistema host. Como seu sistema incorporado tem um processador diferente, voc precisa de uma compilao cruzada toolchain - uma compilao toolchain que roda em seu sistema host, mas gera cdigo 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 compilao regulares toolchain em seu

host roda em x86 e gera cdigo para x86, enquanto os corta-mato-compilao toolchain em x86 e gera cdigo para ARM. Mesmo que o seu sistema embarcado utiliza um processador x86, voc poderia estar interessado em BuildRoot por duas razes: A compilao toolchain em seu host certamente usa a GNU libc que um completo, mas enorme biblioteca C padro. Em vez de usar Libc GNU no seu sistema alvo, voc pode usar uClibc que uma pequena biblioteca C padro. Se voc quiser usar esta biblioteca C, ento voc precisa de uma compilao toolchain para gerar os binrios ligados com ele. Buildroot pode fazer isso por voc. Buildroot automatiza a construo de um sistema de arquivos raiz com todas as ferramentas necessrias como busybox. Isso torna muito mais fcil do que faz-lo com a mo. Voc pode perguntar por que essa ferramenta necessrio quando voc pode compilar gcc , binutils , uClibc e todas as outras ferramentas mo. claro que isso possvel, mas, lidando com todas as opes de configurao e problemas de cada gcc ou binutils verso muito demorado e desinteressante. Buildroot automatiza esse processo atravs do uso de Makefiles e tem uma coleo de correes para cada gcc e binutils verso para faz-los funcionar na maioria das arquitecturas. Alm disso, BuildRoot fornece uma infra-estrutura para reproduzir o processo de construo do seu kernel, cross-toolchain, e sistema de arquivos raiz incorporado. Ser capaz de reproduzir o processo de construo vai ser til quando um componente precisa ser corrigido ou atualizado ou quando outra pessoa suposto para assumir o projeto.

Obteno BuildRoot
Buildroot releases so feitos aproximadamente a cada 3 meses. Git acesso direto e dirio instantneos tambm esto disponveis, se voc quiser borda mais sangramento. Lanamentos esto disponveis em http://buildroot.net/downloads/ . O ltimo snapshot est sempre disponvel em http://buildroot.net/downloads/snapshots/buildrootsnapshot.tar.bz2 e instantneos anteriores tambm esto disponveis no http://buildroot.net/downloads/snapshots/ . Para fazer o download BuildRoot usando Git, voc pode simplesmente seguir as regras descritas no "Acessando Git" pgina ( http://buildroot.net/git.html ) do site BuildRoot ( http://buildroot.net ). Para os impacientes, aqui vai uma receita rpida:
$ Git clone git: / / git.buildroot.net / buildroot

Usando BuildRoot
Buildroot tem uma boa ferramenta de configurao 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 usurio normal. No h necessidade de ser root para configurar e usar BuildRoot. O primeiro passo executar o assistente de configurao:
$ 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 utilitrio de configurao, assim voc pode precisar instalar o "desenvolvimento" pacotes para as bibliotecas relevantes utilizados pelos utilitrios de configurao. Em Debian-like sistemas, o libncurses5-dev pacote necessrio usar a interface menuconfig, libqt4-dev necessrio para usar a interface xconfig, e libglib2.0-dev, libgtk2.0-dev and libglade2-dev so necessrios para usar a interface gconfig. Para cada entrada do menu na ferramenta de configurao, voc pode encontrar ajuda associado que descreve a finalidade da entrada. Depois que tudo estiver configurado, a ferramenta de configurao gera um .config arquivo que contm a descrio de sua configurao. Ele ser usado pela Makefiles para fazer o que necessrio. Vamos l:
$ Make

Voc nunca deve usar make -jN com BuildRoot: ele no suporta mais alto nvel paralelo fazer. Em vez disso, use o BR2_JLEVEL opo para dizer BuildRoot para executar cada compilao pacote com make -jN . Este comando geralmente execute os seguintes passos: Baixar arquivos de origem (conforme necessrio) Configurar, construir e instalar a compilao 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 sada armazenada em um nico diretrio, output/ . Este diretrio contm vrios subdiretrios: images/ onde todas as imagens (imagem do kernel bootloader, e as imagens do sistema de arquivos raiz) so armazenados. build/ onde todos os componentes, exceto para o toolchain compilao cruzada so construdos (isso inclui ferramentas necessrias para executar BuildRoot no host e pacotes compilados para o alvo). O build/ diretrio contm um subdiretrio para cada um desses componentes. staging/ que contm uma hierarquia semelhante a uma hierarquia do sistema de arquivos raiz. Este diretrio contm a instalao da compilao cruzada toolchain e todos os pacotes userspace selecionados para o alvo. No entanto, este diretrio no se destina a ser o sistema de arquivos raiz para o alvo: ele contm uma grande quantidade de arquivos de desenvolvimento, unstripped binrios e bibliotecas que a tornam muito grandes para um sistema embarcado. Estes arquivos de desenvolvimento so usados para compilar as bibliotecas e aplicaes para o destino que dependem de outras bibliotecas. target/ que contm quase o sistema de arquivos raiz para o alvo: tudo que necessrio est presente, exceto os arquivos de dispositivo em /dev/ (BuildRoot no pode cri-los porque BuildRoot no executado como root e no deseja executar como root) . Portanto, este diretrio no deve ser usado em seu alvo. Em vez disso, voc deve usar uma das imagens construdas no images/ diretrio. Se voc precisa de uma imagem extrada do sistema de

arquivos raiz para a inicializao atravs de NFS, em seguida, usar a imagem gerada em tarball images/ e extra-lo como root. Em comparao com staging/ , target/ contm apenas os arquivos e bibliotecas necessrios para executar os aplicativos de destino selecionado: os arquivos de desenvolvimento (cabealhos, etc) no esto presentes, a menos que o development files in target filesystem opo for selecionada. host/ contm a instalao de ferramentas de compilao para o host que so necessrios para a correcta execuo das BuildRoot, incluindo o toolchain compilao cruzada. toolchain/ contm os diretrios de construo para os diversos componentes do toolchain compilao cruzada.

Constri off-line
Se voc pretende fazer uma compilao offline e s quero baixar todas as fontes que voc selecionou anteriormente no configurador (menuconfig, ou xconfig gconfig), assuntos de ento:
$ Make fonte

Agora voc pode desconectar ou copiar o contedo do seu dl diretrio para a construo de host.

Construo de out-of-rvore
Buildroot suporta a construo de rvore com uma sintaxe semelhante ao kernel Linux. Para us-lo, adicione O <diretrio> = linha de comando make:
$ Make O = / tmp / build

Ou:
$ Cd / tmp / build; fazer O caminho = $ PWD-C / para / buildroot

Todos os arquivos de sada sero localizados sob /tmp/build . Ao usar out-of-rvore constri, o BuildRoot .config ficheiros e temporrias tambm so armazenados no diretrio de sada. Isto significa que voc pode seguramente executar vrios builds em paralelo com a rvore mesma fonte, desde que use diretrios de sada nica. Para facilidade de uso, BuildRoot gera um wrapper Makefile no diretrio de sada - Assim, aps a primeira execuo, voc no precisa mais passar O=.. e -C .. , basta executar (no diretrio de sada):
$ Make <destino>

Variveis de ambiente
Buildroot tambm homenageia algumas variveis de ambiente, quando eles so passados para make ou no meio ambiente: HOSTCXX , o host C + + compilador para usar HOSTCC , o anfitrio do compilador C para uso UCLIBC_CONFIG_FILE=<path/to/.config> , caminho para o arquivo de configurao uClibc, usado para compilar uClibc, se um conjunto de ferramentas interna est sendo construda BUSYBOX_CONFIG_FILE=<path/to/.config> , caminho para o arquivo de configurao Busybox BUILDROOT_DL_DIR para substituir o diretrio que armazena BuildRoot / recupera

arquivos baixados Um exemplo que usa arquivos de configurao localizado no diretrio 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 padro gcc ou g++ para a construo de helperbinrios em seu anfitrio, em seguida, fazer
$ Make HOSTCXX = g + + CABEA-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 disponvel sob output/target/ . Voc pode simplesmente fazer as alteraes aqui e execute make depois - o que ir reconstruir a imagem do sistema de arquivos-alvo. Este mtodo permite que voc faa alguma coisa para o sistema de arquivos de destino, mas se voc decidir reconstruir completamente a sua toolchain e ferramentas, estas alteraes sero perdidas. Crie seu esqueleto prpria meta. Voc pode comear com o esqueleto padro disponvel 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 compilao, o contedo do esqueleto so copiados para a sada / target antes de qualquer instalao do pacote. Na configurao BuildRoot, voc pode especificar o caminho para um script de ps-build, que chamado depois BuildRoot constri todo o software selecionado, mas antes que os pacotes so montados rootfs. O destino da pasta raiz dado como o primeiro argumento para o script, e esse script pode ser usado para programas de cpia, os dados estticos ou qualquer outro arquivo necessrio 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 desnecessrios, voc deve corrigir esse pacote ao invs de trabalhar em torno dele com um script de limpeza ps-compilao. 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 ento permitir que este pacote especial no sistema de configurao.

Personalizando a configurao Busybox


Busybox muito configurvel, e voc pode querer personaliz-lo. Voc pode seguir estes passos simples para fazer isso. Este mtodo no ideal, mas simples e funciona: 1. Fazer uma compilao inicial de BuildRoot, com busybox, sem tentar personaliz-lo. 2. Invoke make busybox-menuconfig . A ferramenta de configurao aparece agradvel, e voc pode personalizar tudo. 3. Executar a compilao de BuildRoot novamente. Caso contrrio, voc pode simplesmente mudar o package/busybox/busybox<version>.config arquivo, se voc sabe as opes que pretende alterar, sem usar a ferramenta de configurao.

Se voc quiser usar um arquivo de configurao existentes para busybox, ento consulte a seco variveis de ambiente .

Personalizando a configurao uClibc


Assim como BusyBox , uClibc oferece uma srie de opes de configurao. Eles permitem que voc selecione vrias funcionalidades dependendo de suas necessidades e limitaes. A maneira mais fcil de modificar a configurao do uClibc seguir estes passos: 1. Fazer uma compilao inicial de BuildRoot sem tentar personalizar uClibc. 2. Invoke make uclibc-menuconfig . O assistente de configurao agradvel, semelhante ao usado no kernel do Linux ou BuildRoot, aparece. Faa as alteraes de configurao 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 configurao uClibc (configurao opo BR2_UCLIBC_CONFIG ) para usar essa configurao em vez do padro. 4. Executar a compilao de BuildRoot novamente. Caso contrrio, voc pode simplesmente mudar toolchain/uClibc/uClibc.config , sem correr o assistente de configurao. Se voc quiser usar um arquivo de configurao existentes para uClibc, ento consulte a seco variveis de ambiente .

Personalizando a configurao do kernel Linux


A configurao 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 configurao existentes para Linux, ento consulte a seco variveis de ambiente .

Compreenso de como reconstruir pacotes


Uma das perguntas mais comuns feitas pelos usurios BuildRoot como reconstruir um determinado pacote ou como remover um pacote sem reconstruir tudo do zero. Remoo de um pacote est atualmente no suportada pelo BuildRoot sem reconstruo do zero. Isto porque BuildRoot no acompanhar o que o pacote instala arquivos na output/staging e output/target diretrios. No entanto, a implementao de remoo do pacote limpa est na TODO list dos desenvolvedores BuildRoot. A maneira mais fcil reconstruir um nico pacote a partir do zero remover o diretrio construir em output/build . Buildroot ento re-extract, re-configurar, re-re-compilar e instalar este pacote a partir do zero. No entanto, se voc no quiser reconstruir o pacote completamente do zero, uma melhor compreenso dos internals BuildRoot necessrio. Internamente, para acompanhar os passos que tm sido feitos e que h ainda muito a ser feito, BuildRoot mantm arquivos de selo (arquivos vazios que apenas dizer se essa ou aquela ao tem sido feito). O problema que esses arquivos no so uniformemente selo chamado e manipulados pelos pacotes diferentes, por isso alguma compreenso do pacote especial necessria.

Para pacotes contando com infra-estruturas BuildRoot pacotes (veja nesta seo para mais detalhes), os arquivos de selo so relevantes: output/build/packagename-version/.stamp_configured . Se removido, BuildRoot ir acionar a recompilao do pacote a partir da etapa de configurao (execuo de ./configure ). output/build/packagename-version/.stamp_built . Se removido, BuildRoot ir acionar a recompilao do pacote da etapa de compilao (execuo de make ). Para outros pacotes, uma anlise do arquivo package.mk especfico necessrio. Por exemplo, o Makefile zlib costumava olhar assim (antes de ser convertido para a infra-estrutura pacote genrico):
$ (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 reconfigurao, voc precisa remover output/build/zlibversion/.configured . Se voc deseja acionar apenas a recompilao, voc precisa remover output/build/zlib-version/libz.a . Note-se que a maioria dos pacotes, se no todos, sero progressivamente transferidos ao longo da infra-estrutura genrica ou autotools, tornando muito mais fcil 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 opes corretas. Ele tambm inclui patches para vrios pacotes de software - principalmente os envolvidos na cadeia de ferramenta cross-compilao ( gcc , binutils e uClibc ). H, basicamente, um Makefile por pacote de software, e eles so nomeados com o .mk extenso. Makefiles so divididos em trs seces principais: toolchain (no toolchain/ diretrio) contm os arquivos Makefiles e associados para todos os softwares relacionados com o toolchain compilao cruzada: binutils , gcc , gdb , kernel-headers e uClibc . pacote (no package/ diretrio) contm os arquivos Makefiles e associados para todas as ferramentas do espao do usurio que BuildRoot pode compilar e adicionar ao sistema de arquivos raiz de destino. H um sub-diretrio por ferramenta. alvo (no target diretrio) contm os arquivos Makefiles e associados para software relacionado gerao da imagem do sistema de arquivos raiz meta. Quatro tipos de sistemas de arquivos so suportados: ext2, jffs2, cramfs e squashfs. Para cada um deles h um subdiretrio com os arquivos necessrios. H tambm um default/ diretrio que contm o esqueleto do sistema de arquivos-alvo. Cada diretrio contm 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 configurao ferramenta de descrio. Ele descreve as opes relacionadas com o pacote. O Makefile principal executa as seguintes etapas (uma vez que a configurao feita): 1. Criar todos os diretrios de sada: staging , target , build , stamps , etc no diretrio de sada ( output/ por padro, outro valor pode ser especificado usando O= ) 2. Gerar todas as metas traadas na BASE_TARGETS varivel. Quando um toolchain interna usada, isto significa gerar a compilao cruzada toolchain. Quando um toolchain externa usada, isto significa verificar as caractersticas do conjunto de ferramentas externas e import-la no ambiente BuildRoot. 3. Gerar todas as metas traadas na TARGETS varivel. Esta varivel preenchida por Makefiles todos os componentes individuais ". Gerando essas metas ir desencadear a compilao dos pacotes userspace (bibliotecas, programas), o kernel, o bootloader ea gerao das imagens do sistema de arquivos raiz, dependendo da configurao.

Criar o seu prprio suporte de placa


Criar o seu prprio suporte de placa em BuildRoot permite que os usurios de uma plataforma de hardware especfico para facilmente construir um sistema que conhecido para o trabalho. Para isso, voc precisa criar uma configurao BuildRoot normal que constri um sistema bsico para o hardware: kernel, toolchain, bootloader, sistema de arquivos e um userspace simples Busybox-only. Nenhum pacote especfico deve ser selecionado: a configurao deve ser o mnimo possvel, e s deve construir um sistema Busybox fundamentais de trabalho para a plataforma alvo. Pode, claro, usar as configuraes mais complicadas para os seus projetos internos, mas o projeto s ir integrar BuildRoot configuraes da placa bsica. Isto porque selees de pacotes so altamente especfico do aplicativo. Depois de ter uma configurao conhecida de trabalho, executar make savedefconfig . Isso ir gerar um mnimo de defconfig arquivo na raiz da rvore fonte BuildRoot. Mova este arquivo para a configs/ diretrio e renome-lo MYBOARD_defconfig . Recomenda-se usar o mximo possvel verses originais do kernel do Linux e gerenciadores de partida, e para utilizar, tanto quanto possvel kernel padro e configuraes bootloader. Se eles esto incorretas para sua plataforma, ns encorajamos voc a enviar correes para os projetos correspondentes a montante. No entanto, nesse meio tempo, voc pode querer armazenar kernel ou bootloader configurao ou patches especficos para sua plataforma de destino. Para fazer isso, crie um diretrio board/MANUFACTURER e um subdiretrio board/MANUFACTURER/BOARDNAME (aps a substituio, claro, fabricante e BOARDNAME com os valores apropriados, em letras minsculas). Voc pode ento armazenar seus patches e configuraes nestes diretrios, e referenci-los a partir da configurao BuildRoot principal.

Usando o gerado BuildRoot toolchain fora


Voc pode querer compilar, para o seu alvo, os seus prprios programas ou outros softwares que no so embalados em BuildRoot. Para fazer isso, voc pode usar o toolchain que foi gerado pelo BuildRoot. O toolchain gerada pelo BuildRoot est localizado por padro na output/host/ . A maneira mais simples para us-lo adicionar output/host/usr/bin/ para a varivel de ambiente PATH e depois de usar ARCH-linux-gcc , ARCH-linux-objdump , ARCH-linux-ld , etc possvel mudar o local da toolchain - mas ento --sysroot deve ser passado sempre que o

compilador chamado a dizer onde as bibliotecas e arquivos de cabealho so. Tambm possvel gerar o BuildRoot toolchain em um diretrio que no seja output/host usando o Build options -> Host dir opo. Isto pode ser til se o toolchain devem ser compartilhados com outros usurios.

Usando ccache em BuildRoot


ccache um cache do compilador. Ele armazena os arquivos objeto resultante de cada processo de compilao, e capaz de pular compilao futuro do mesmo arquivo de origem (com mesmo compilador e argumentos mesmo) usando os arquivos pr-existentes objeto. Ao fazer constri quase idnticos a partir do zero vrias vezes, ele pode muito bem acelerar o processo de construo. 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 compilao alvo. O cache est localizada em $HOME/.buildroot-ccache . Ela armazenada fora do diretrio de sada BuildRoot para que ele possa ser compartilhado por constri BuildRoot separado. Se voc quer se livrar do cache, basta remover este diretrio. Voc pode obter estatsticas sobre o cache (seu tamanho, nmero de hits, misses, etc), executando make ccache-stats .

Localizao de pacotes baixados


Pode ser til saber que o tarballs diferentes que so baixados pela Makefiles so todos armazenados no DL_DIR que por padro o dl diretrio. til, por exemplo, se voc quiser manter uma verso 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 verses. Se voc mantm vrias rvores BuildRoot, talvez seja melhor ter um local de download compartilhada. Isso pode ser acessado atravs da criao de um link simblico do dl diretrio 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 varivel de ambiente. Se isso for definido, ento o valor da DL_DIR no projeto substitudo. 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 razes: voc j tem um conjunto de ferramentas que conhecido por trabalhar para a sua CPU especfica voc quiser acelerar o processo de construo BuildRoot saltando a longa pea construir toolchain o recurso de gerao de toolchain BuildRoot no suficientemente flexvel para voc (por exemplo, se voc precisa gerar um sistema com glibc, em vez de uClibc) Buildroot suporta o uso de toolchains existentes atravs de um mecanismo chamado externo toolchain. O mecanismo externo toolchain est habilitado no Toolchain menu, selecionando

External toolchain no Toolchain type . Ento, voc tem trs solues 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 disponveis. Esta definitivamente a soluo mais fcil. 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 disponveis, 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 soluo no Toolchain lista. necessrio preencher o Toolchain path , Toolchain prefix e External toolchain C library opes. Ento, 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 no. Se o seu toolchain externa usa a biblioteca uClibc, ento voc tem que dizer se ele suporta BuildRoot largefile, IPv6, RPC, larga-char locale, programa de invocao, tpicos e C + +. No incio da execuo, BuildRoot vai dizer se as opes selecionadas no corresponder configurao 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 no for, no hesite em entrar em contato com os desenvolvedores. No apoiamos toolchains do ELDK de Denx , por duas razes: O ELDK no contm 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 no pode importar o sysroot do toolchain, pois poderia conter centenas de megabytes de pr-compilados bibliotecas que so normalmente construdas por BuildRoot. O toolchains ELDK ter um mecanismo completamente fora do padro personalizado para lidar com mltiplas variantes biblioteca. Em vez de usar o padro GCC mecanismo multilib, o ELDK ARM diferentes usos links simblicos para o compilador para diferenciar entre as variantes biblioteca (por ARM macio-float e ARM VFP), eo PowerPC ELDK compilador usa uma CROSS_COMPILE varivel de ambiente. Este comportamento no-padro dificulta o apoio ELDK em BuildRoot. Ns tambm no suportam o uso da distribuio toolchain (ou seja, a biblioteca do gcc / binutils / C instalado pela sua distribuio) como o conjunto de ferramentas para criar software para o destino. Isso ocorre porque sua distribuio toolchain no um "puro" toolchain (ou seja, apenas com o C / C + + biblioteca), por isso no 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 compilao cruzada toolchain com BuildRoot ou Crosstool NG.

Adicionando novos pacotes BuildRoot


Esta seo aborda como novos pacotes (bibliotecas userspace ou aplicaes) podem ser integrados em BuildRoot. Ele tambm mostra como os pacotes existentes so integrados, o que necessrio para a correo de problemas ou ajuste sua configurao.

Diretrio do pacote Config.in arquivo O .mk arquivo Makefile para pacotes genricos: tutorial Makefile para pacotes genricos: referncia Makefile para autotools baseado pacotes: tutorial Makefile para autotools baseado pacotes: de referncia Makefile para CMake baseado pacotes: tutorial Makefile para CMake baseado pacotes: de referncia Manual Makefile: tutorial Gettext integrao e interao com pacotes

Diretrio do pacote
Antes de mais nada, crie um diretrio sob o package software para o seu diretrio, por exemplo libfoo . Alguns pacotes foram agrupados por tema em um sub-diretrio: multimedia , java , x11r7 , e games . Se o seu pacote se encaixa em uma dessas categorias, ento criar o seu diretrio do pacote nestes.

Config.in arquivo
Em seguida, crie um arquivo chamado Config.in . Este arquivo conter as descries opo relacionada com a nossa libfoo software que ser usado e exibido na ferramenta de configurao. Deve conter, basicamente:
configurao BR2_PACKAGE_LIBFOO bool "libfoo" ajuda Este um comentrio que explica o que libfoo. http://foosoftware.org/libfoo/

Claro, voc pode adicionar outras opes 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 documentao para esta sintaxe est disponvel 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 subdiretrio se voc decidiu colocar o pacote em uma das categorias existentes). Os ficheiros includos existem classificados em ordem alfabtica por categoria e no so 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 difcil. 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 genricos (no usando autotools): Estes so 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 configurao, compilao, instalao e limpeza do pacote. Esta infra-estrutura deve ser utilizado para todos os pacotes que no usam o autotools como seu sistema de compilao. No futuro, outras infra-estruturas especializadas poderiam ser escritas para outros sistemas de construo. Ns cobri-los atravs de um tutorial e uma referncia . Makefiles para autotools baseado software (autoconf, automake, etc): Ns fornecemos uma infra-estrutura dedicada para tais pacotes, pois autotools um sistema de construo muito comum. Esta infra-estrutura deve ser utilizado para novos pacotes que dependem do autotools como seu sistema de compilao. Ns cobri-los atravs de um tutorial e uma referncia . Manual Makefiles: Estes so atualmente obsoletos, e nenhum novo manual de Makefiles deve ser adicionada. No entanto, uma vez que ainda h muitos deles na rvore, ns mantlos documentado em um tutorial . Makefile para pacotes genricos: 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 comea na linha 6-8, com informaes de metadados: a verso 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 variveis devem comear com o mesmo prefixo, LIBFOO_ neste caso. Este prefixo sempre a verso maiscula 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 espao de teste. Isso muitas vezes necessrio para as bibliotecas, uma vez que deve instalar arquivos de cabealho e arquivos de desenvolvimento outro no espao de teste. Isso ir garantir que os comandos listados na

LIBFOO_INSTALL_STAGING_CMDS varivel ser executado. Na linha 10, ns especificar a lista de dependncias este pacote depende. Essas dependncias so listados em termos de nomes em minsculo 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 so construdos e instalados antes do pacote atual inicia a sua configurao. O resto do Makefile define o que deve ser feito em diferentes etapas da compilao do pacote de configurao e instalao. 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 espao de preparao . LIBFOO_INSTALL_TARGET_CMDS diz que medidas devem ser executadas para instalar o pacote no espao-alvo. Todos estes passos dependem do $(@D) varivel, que contm o diretrio onde o cdigo-fonte do pacote foi extrado. Finalmente, na linha 27, chamamos o GENTARGETS que gera, de acordo com as variveis definidas anteriormente, todo o cdigo Makefile necessrio para tornar o seu pacote de trabalho. Makefile para pacotes genricos: referncia O GENTARGETS macro recebe trs argumentos: O primeiro argumento o prefixo diretrio do pacote. Se o seu pacote est no package/libfoo , o prefixo de diretrio package . Se o seu pacote est no package/editors/foo , o prefixo de diretrio deve ser package/editors . O segundo argumento o nome do pacote escrito em minscula. Ele deve corresponder ao prefixo das variveis no .mk arquivo e deve coincidir com o nome da opo de configurao no Config.in arquivo. Por exemplo, se o nome do pacote libfoo , ento as variveis no .mk arquivo deve comear com LIBFOO_ ea opo de configurao 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 no for especificado, presume-se que um pacote de destino. Veja os detalhes abaixo. Para um determinado pacote, em um nico .mk arquivo, possvel 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 compilao do pacote de destino exige algumas ferramentas para ser instalado no host. Se o nome do pacote libfoo , ento o nome do pacote para o alvo tambm libfoo , enquanto o nome do pacote para o host host-libfoo . Estes nomes devem ser utilizados nas variveis dependncias 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 definies de variveis. Para o pacote de destino, o GENTARGETS utiliza as variveis definidas pelo arquivo mk e prefixados pelo nome do pacote minsculo:. LIBFOO_* . Para o pacote do host, ele usa o HOST_LIBFOO_* . Para algumas variveis, se o HOST_LIBFOO_ varivel prefixado no existe, a infra-estrutura pacote usa a varivel correspondente prefixado por LIBFOO_ . Isto feito para as variveis que possam ter o mesmo valor para ambos alvo e pacotes de host. Veja os detalhes abaixo. A lista de variveis que podem ser definidos em um .mk arquivo para dar informaes de

metadados (assumindo que o nome do pacote libfoo ): LIBFOO_VERSION , obrigatria, deve conter a verso do pacote. Note que se HOST_LIBFOO_VERSION no existe, assumido como sendo o mesmo que LIBFOO_VERSION . Tambm pode ser um Subversion ou Git sucursal ou tag, para pacotes que so buscadas diretamente de seu sistema de controle de reviso. Exemplo: LIBFOO_VERSION = 0.1.2 LIBFOO_SOURCE pode conter o nome do tarball do pacote. Se HOST_LIBFOO_SOURCE no especificado, o padro LIBFOO_VERSION . Se nenhum for especificado, ento 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 no especificado, o padro LIBFOO_PATCH . Observe tambm que um outro mecanismo est disponvel para corrigir um pacote: todos os arquivos da forma packagenamepackageversion-description.patch presente no diretrio do pacote dentro BuildRoot ser aplicada para o pacote aps a extrao. LIBFOO_SITE pode conter a localizao do pacote de Internet. Ela pode ser a localizao de HTTP ou FTP de um tarball, ou o URL de um repositrio Git ou Subversion (veja LIBFOO_SITE_METHOD abaixo). Se HOST_LIBFOO_SITE no especificado, o padro LIBFOO_SITE . Se nenhum for especificado, ento 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 mtodo para buscar o cdigo fonte do pacote. Ela pode ser wget (para normal FTP / HTTP downloads de tarballs), svn , git ou bzr . Quando no especificado, adivinhado a partir do URL dado em LIBFOO_SITE : svn:// , git:// e bzr:// URLs ir utilizar o svn , git e bzr mtodos, respectivamente. Todos os outros tipos de URL ir usar o wget mtodo. Assim, por exemplo, no caso de um pacote cujo cdigo fonte est disponvel atravs do repositrio no Subversion HTTP, deve-se especifique LIBFOO_SITE_METHOD=svn . Para svn e git mtodos, o que faz BuildRoot um checkout / clone do repositrio que ento tarballed e armazenados no cache de download. Constri seguinte no checkout / clone de novo, mas vai usar o tarball diretamente. Quando HOST_LIBFOO_SITE_METHOD no for especificado, o padro o valor de LIBFOO_SITE_METHOD . Veja package/multimedia/tremor/ para um exemplo. LIBFOO_DEPENDENCIES lista as dependncias (em termos de nome do pacote) que so necessrios para o pacote alvo atual para compilar. Essas dependncias so garantidos para ser compilado e instalado antes da configurao do pacote actual comea. De maneira semelhante, HOST_LIBFOO_DEPENDENCIES listas a dependncia para o pacote do host atual. LIBFOO_INSTALL_STAGING pode ser configurada para YES ou NO (padro). Se definido como YES , ento os comandos no LIBFOO_INSTALL_STAGING_CMDS variveis so executadas para instalar o pacote para o diretrio teste. LIBFOO_INSTALL_TARGET pode ser definida como YES (default) ou NO . Se definido como YES , ento os comandos no LIBFOO_INSTALL_TARGET_CMDS variveis so executadas para instalar o pacote para o diretrio de destino. A maneira recomendada para definir essas variveis usar a seguinte sintaxe:
LIBFOO_VERSION = 2,32

Agora, as variveis que definem o que deve ser realizado em diferentes etapas do processo de construo. LIBFOO_CONFIGURE_CMDS , usado para listar as aes a serem executadas para configurar o pacote antes de sua compilao LIBFOO_BUILD_CMDS , usado para listar as aes a serem executadas para compilar o pacote HOST_LIBFOO_INSTALL_CMDS , usado para listar as aes a serem executadas para instalar o pacote, quando o pacote um pacote de host. O pacote deve instalar seus arquivos para o diretrio dado por $(HOST_DIR) . Todos os arquivos, incluindo arquivos de desenvolvimento tais como cabealhos devem ser instalados, uma vez que outros pacotes podem ser compilados, em cima do pacote. LIBFOO_INSTALL_TARGET_CMDS , usado para listar as aes a serem executadas para instalar o pacote para o diretrio de destino, quando o pacote um pacote de destino. O pacote deve instalar seus arquivos para o diretrio dado por $(TARGET_DIR) . Apenas os arquivos necessrios para a documentao e execuo do pacote deve ser instalado. Arquivos de cabealho no deve ser instalado, eles sero copiados para o alvo, se a development files in target filesystem opo for selecionada. LIBFOO_INSTALL_STAGING_CMDS , usado para listar as aes a serem executadas para instalar o pacote para o diretrio provisrio, quando o pacote um pacote de destino. O pacote deve instalar seus arquivos para o diretrio dado por $(STAGING_DIR) . Todos os arquivos de desenvolvimento deve ser instalado, pois eles podem ser necessrios para compilar outros pacotes. LIBFOO_CLEAN_CMDS , usado para listar as aes a executar para limpar o diretrio de compilao do pacote. LIBFOO_UNINSTALL_TARGET_CMDS , usado para listar as aes para desinstalar o pacote do alvo diretrio $(TARGET_DIR) LIBFOO_UNINSTALL_STAGING_CMDS , usado para listar as aes para desinstalar o pacote do teste diretrio $(STAGING_DIR) . A maneira preferida para definir essas variveis :
definir LIBFOO_CONFIGURE_CMDS aco 1 aco 2 aco 3 ENDEF

Nas definies de ao, voc pode usar as seguintes variveis: $(@D) , que contm o diretrio em que o cdigo fonte do pacote foi descompactado. $(TARGET_CC) , $(TARGET_LD) , etc para obter o alvo compilao cruzada utilitrios $(TARGET_CROSS) para obter o prefixo de compilao cruzada toolchain Claro que o $(HOST_DIR) , $(STAGING_DIR) e $(TARGET_DIR) variveis para instalar os pacotes corretamente.

O ltimo recurso da infra-estrutura genrica a capacidade de adicionar os ganchos. Estes definem novas aces a realizar, aps as etapas existentes. A maioria dos ganchos no so muito teis para os pacotes genricos, desde o .mk arquivo j tem total controle sobre as aes realizadas em cada etapa da construo do pacote. Os ganchos so mais teis para pacotes usando a infra-estrutura autotools descrito abaixo. No entanto, uma vez que so fornecidas pela infra-estrutura genrica, que esto documentadas aqui. A exceo LIBFOO_POST_PATCH_HOOKS . Remendar o pacote no definido pelo usurio, de modo LIBFOO_POST_PATCH_HOOKS ser userful para pacotes genricos.

Os pontos de gancho a seguir esto disponveis: 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 variveis so as listas de nomes de variveis contendo aes a serem realizadas neste momento gancho. Isto permite que vrios 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: 04: 05: 06: 07: 08: 09: 10: 11: 12: 13: 14: ################################################ ############# # # libfoo # ################################################ ############# LIBFOO_VERSION = 1,0 LIBFOO_SOURCE = libfoo-$ (LIBFOO_VERSION) tar.gz. LIBFOO_SITE = http://www.foosoftware.org/download LIBFOO_INSTALL_STAGING = YES LIBFOO_INSTALL_TARGET = YES LIBFOO_CONF_OPT = - enable-shared LIBFOO_DEPENDENCIES = libglib2 host-pkg-config $ (eval $ (AUTOTARGETS chamada, pacote, libfoo))

Na linha 6, ns declaramos a verso do pacote. Na linha 7 e 8, ns declaramos o nome do tarball e da localizao do tarball na web. Buildroot far automaticamente o download do tarball a partir desta localizao. Na linha 9, dizemos BuildRoot para instalar o pacote para o diretrio teste. O diretrio provisrio, localizado na output/staging/ o diretrio onde todos os pacotes esto instalados, incluindo arquivos de seu desenvolvimento, etc Por padro, os pacotes no so instalados no diretrio temporrio, pois normalmente, apenas as bibliotecas precisam ser instalados no encenao diretrio: arquivos de seu desenvolvimento so necessrios para compilar outras bibliotecas ou aplicativos, dependendo deles. Tambm por padro, quando a instalao de teste for ativado, os pacotes so instalados neste local usando o make install comando. Na linha 10, dizemos BuildRoot para tambm instalar o pacote para o diretrio de destino. Este diretrio contm o que se tornar o sistema de arquivos raiz em execuo no alvo. Normalmente, tentamos no instalar arquivos de cabealho e instalar verses despojado do binrio. Por padro, instalao de destino ativado, assim, de facto, esta linha no estritamente necessrio. Tambm

por padro, os pacotes so instalados neste local usando o make install comando. Na linha 11, dizemos BuildRoot passar uma opo de configurao personalizada, que ser passado para o ./configure script antes de configurar e construir o pacote. Na linha 12, ns declaramos nossas dependncias, de modo que eles so construdos antes do processo de construo do nosso pacote comea. Finalmente, na linha linha 14, ns invocamos o AUTOTARGETS macro que gera todas as regras Makefile que realmente permite que o pacote a ser construdo. Makefile para pacotes autotools: referncia A macro principal da infra-estrutura pacote autotools AUTOTARGETS . Ele tem o mesmo nmero de argumentos eo semntico mesmo que o GENTARGETS macro, que o principal macro da infraestrutura pacote genrico. Para pacotes autotools, a capacidade de ter os pacotes-alvo e de acolhimento tambm est disponvel (e na verdade amplamente utilizado). Assim como a infra-estrutura genrica, a infra-estrutura autotools funciona atravs da definio de uma srie de variveis antes de chamar o AUTOTARGETS macro. Primeiro, todas as variveis do pacote de metadados informaes que existem na infra-estrutura genrica tambm existem no autotools A poucas variveis adicionais, especficas para a infra-estrutura autotools, tambm pode ser definida. Muitos deles s so teis em casos muito especficos, pacotes tpicos, portanto, usar apenas alguns deles. LIBFOO_SUBDIR pode conter o nome de um subdiretrio dentro do pacote que contm o script configure. Isso til se, por exemplo, o script configure principal no est na raiz da rvore extrada pelo tarball. Se HOST_LIBFOO_SUBDIR no especificado, o padro LIBFOO_SUBDIR . LIBFOO_CONF_ENV , para especificar variveis de ambiente adicionais para passar para o script configure. Por padro, o vazio. LIBFOO_CONF_OPT , para especificar opes adicionais do configure para passar para o script configure. Por padro, o vazio. LIBFOO_MAKE , para especificar um suplente make de comando. Isto tipicamente til quando paralelo fazer habilitado na configurao (usando BR2_JLEVEL ), mas que esse recurso deve ser desativado para o determinado pacote, por um motivo ou outro. Por padro, definido como $(MAKE) . Se a construo paralela no suportada pelo pacote, ento ele deve ser definido como LIBFOO_MAKE=$(MAKE1) . LIBFOO_MAKE_ENV , para especificar variveis de ambiente adicionais para passar a fazer na etapa de compilao. Estes so passadas antes do make de comando. Por padro, o vazio. LIBFOO_MAKE_OPT , para especificar variveis adicionais para passar a fazer na etapa de compilao. Estes so passados aps a make comando. Por padro, o vazio. LIBFOO_AUTORECONF , diz se o pacote deve ser autoreconfigured ou no (ou seja, se o script configure e arquivos Makefile.in deve ser re-gerado pelo re-executar autoconf, automake, libtool, etc.) Os valores vlidos so YES e NO . Por padro, o valor NO LIBFOO_AUTORECONF_OPT para especificar opes adicionais passados para o programa autoreconf se LIBFOO_AUTORECONF=YES . Por padro, o vazio. LIBFOO_LIBTOOL_PATCH diz se o patch para corrigir BuildRoot libtool compilao cruzada questes devem ser aplicados ou no. Os valores vlidos so YES e NO . Por padro, o valor YES LIBFOO_INSTALL_STAGING_OPT contm opes de make usado para instalar o pacote para o diretrio provisrio. Por padro, o valor DESTDIR=$$(STAGING_DIR)

install , o que correto para a maioria dos pacotes autotools. Ainda possvel substitulo. LIBFOO_INSTALL_TARGET_OPT contm opes de make usado para instalar o pacote para o diretrio de destino. Por padro, o valor DESTDIR=$$(TARGET_DIR) install . O valor padro correto para a maioria dos pacotes autotools, mas ainda possvel substitu-lo se necessrio. LIBFOO_CLEAN_OPT contm opes de make usado para limpar o pacote. Por padro, o valor clean . LIBFOO_UNINSTALL_STAGING_OPT , contm opes de make usado para desinstalar o pacote do diretrio provisrio. Por padro, o valor DESTDIR=$$(STAGING_DIR) uninstall . LIBFOO_UNINSTALL_TARGET_OPT , contm opes de make usado para desinstalar o pacote do diretrio de destino. Por padro, o valor DESTDIR=$$(TARGET_DIR) uninstall .

Com a infra-estrutura autotools, todos os passos necessrios para construir e instalar os pacotes j esto definidos, e eles geralmente funcionam bem para a maioria dos autotools pacotes baseados. No entanto, quando necessrio, ainda possvel personalizar o que feito em qualquer passo particular: Pela adio de um gancho de ps-operatrio (aps o patch extraia, configurar, construir ou instalar). Consulte a documentao de referncia da infra-estrutura genrica para mais detalhes. , Substituindo um dos passos. Por exemplo, mesmo que a infra-estrutura autotools usado, se o pacote .mk arquivo define seus prprios LIBFOO_CONFIGURE_CMDS varivel, que ser usado em vez do padro autotools um. No entanto, usando este mtodo deve ser restrito a casos muito especficos. No 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: 04: 05: 06: 07: 08: 09: 10: 11: 12: 13: 14: ################################################ ############# # # libfoo # ################################################ ############# LIBFOO_VERSION = 1,0 LIBFOO_SOURCE = libfoo-$ (LIBFOO_VERSION) tar.gz. LIBFOO_SITE = http://www.foosoftware.org/download LIBFOO_INSTALL_STAGING = YES LIBFOO_INSTALL_TARGET = YES LIBFOO_CONF_OPT =-DBUILD_DEMOS = ON LIBFOO_DEPENDENCIES = libglib2 host-pkg-config $ (eval $ (CMAKETARGETS chamada, pacote, libfoo))

Na linha 6, ns declaramos a verso do pacote. Na linha 7 e 8, ns declaramos o nome do tarball e da localizao do tarball na web. Buildroot far automaticamente o download do tarball a partir desta localizao. Na linha 9, dizemos BuildRoot para instalar o pacote para o diretrio teste. O diretrio provisrio, localizado na output/staging/ o diretrio onde todos os pacotes esto instalados, incluindo arquivos de seu desenvolvimento, etc Por padro, os pacotes no so instalados no diretrio temporrio, pois normalmente, apenas as bibliotecas precisam ser instalados no encenao diretrio:

arquivos de seu desenvolvimento so necessrios para compilar outras bibliotecas ou aplicativos, dependendo deles. Tambm por padro, quando a instalao de teste for ativado, os pacotes so instalados neste local usando o make install comando. Na linha 10, dizemos BuildRoot para tambm instalar o pacote para o diretrio de destino. Este diretrio contm o que se tornar o sistema de arquivos raiz em execuo no alvo. Normalmente, tentamos no instalar arquivos de cabealho e instalar verses despojado do binrio. Por padro, instalao de destino ativado, assim, de facto, esta linha no estritamente necessrio. Tambm por padro, os pacotes so instalados neste local usando o make install comando. Na linha 11, dizemos BuildRoot passar as opes personalizadas para CMake quando configurar o pacote. Na linha 12, ns declaramos nossas dependncias, de modo que eles so construdos antes do processo de construo do nosso pacote comea. Finalmente, na linha linha 14, ns invocamos o CMAKETARGETS macro que gera todas as regras Makefile que realmente permite que o pacote a ser construdo. Makefile para pacotes CMake: referncia A macro principal da infra-estrutura pacote CMake CMAKETARGETS . Ele tem o mesmo nmero de argumentos eo semntico mesmo que o GENTARGETS macro, que o principal macro da infraestrutura pacote genrico. Para pacotes CMake, a capacidade de ter os pacotes-alvo e de acolhimento tambm est disponvel. Assim como a infra-estrutura genrica, a infra-estrutura CMake funciona atravs da definio de uma srie de variveis antes de chamar o CMAKETARGETS macro. Primeiro, todas as variveis do pacote de metadados informaes que existem na infra-estrutura genrica tambm existem no CMake A poucas variveis adicionais, especficas para a infra-estrutura CMake, tambm pode ser definida. Muitos deles s so teis em casos muito especficos, pacotes tpicos, portanto, usar apenas alguns deles. LIBFOO_SUBDIR pode conter o nome de um subdiretrio dentro do pacote que contm o arquivo CMakeLists.txt principal. Isso til se, por exemplo, o arquivo CMakeLists.txt principal no est na raiz da rvore extrada pelo tarball. Se HOST_LIBFOO_SUBDIR no especificado, o padro LIBFOO_SUBDIR . LIBFOO_CONF_ENV , para especificar variveis de ambiente adicionais para passar para CMake. Por padro, o vazio. LIBFOO_CONF_OPT , para especificar opes adicionais do configure para passar para CMake. Por padro, o vazio. LIBFOO_MAKE , para especificar um suplente make de comando. Isto tipicamente til quando paralelo fazer habilitado na configurao (usando BR2_JLEVEL ), mas que esse recurso deve ser desativado para o determinado pacote, por um motivo ou outro. Por padro, definido como $(MAKE) . Se a construo paralela no suportada pelo pacote, ento ele deve ser definido como LIBFOO_MAKE=$(MAKE1) . LIBFOO_MAKE_ENV , para especificar variveis de ambiente adicionais para passar a fazer na etapa de compilao. Estes so passadas antes do make de comando. Por padro, o vazio. LIBFOO_MAKE_OPT , para especificar variveis adicionais para passar a fazer na etapa de compilao. Estes so passados aps a make comando. Por padro, o vazio. LIBFOO_INSTALL_STAGING_OPT contm opes de make usado para instalar o pacote para o diretrio provisrio. Por padro, o valor DESTDIR=$$(STAGING_DIR) install , o que correto para a maioria dos pacotes CMake. Ainda possvel substitu-lo.

LIBFOO_INSTALL_TARGET_OPT contm opes de make usado para instalar o pacote para o diretrio de destino. Por padro, o valor DESTDIR=$$(TARGET_DIR) install . O valor padro correto para a maioria dos pacotes CMake, mas ainda possvel substitu-lo se necessrio. LIBFOO_CLEAN_OPT contm opes de make usado para limpar o pacote. Por padro, o valor clean . Com a infra-estrutura CMake, todos os passos necessrios para construir e instalar os pacotes j esto definidos, e eles geralmente funcionam bem para a maioria dos pacotes baseados CMake. No entanto, quando necessrio, ainda possvel personalizar o que feito em qualquer passo particular: Pela adio de um gancho de ps-operatrio (aps o patch extraia, configurar, construir ou instalar). Consulte a documentao de referncia da infra-estrutura genrica para mais detalhes. , Substituindo um dos passos. Por exemplo, mesmo que a infra-estrutura CMake usado, se o pacote .mk arquivo define seus prprios LIBFOO_CONFIGURE_CMDS varivel, que ser usado em vez do padro CMake um. No entanto, usando este mtodo deve ser restrito a casos muito especficos. No us-la no caso geral. Manual Makefile: tutorial NOTA: novo manual de makefiles no deve ser criado, e manual de makefiles existentes devem ser convertidos tanto para o genrico, autotools ou infra-estrutura cmake. Esta seo 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_verso) 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: # opes 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 binrio executvel nico. Para outros softwares, como bibliotecas ou coisas mais complexas com mltiplos binrios, deve ser adaptado. Para exemplos olhar para o outro *.mk arquivos no package diretrio. Nas linhas 11/06 , um par de variveis teis so definidos: LIBFOO_VERSION : A verso 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 diretrio onde LIBFOO_SOURCE pode ser encontrado. LIBFOO_DIR : O diretrio no qual o software ser configurado e compilado. Basicamente, um subdiretrio do BUILD_DIR que criado em cima de descompresso do tarball. LIBFOO_BINARY : nome do binrio do Software. Como disse anteriormente, este um exemplo para um pacote com um nico binrio. LIBFOO_TARGET_BINARY : O caminho completo do binrio dentro do sistema de arquivos-alvo. Linhas 13-14 definir um alvo que faz o download do tarball do site remoto para o diretrio 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 dependncias 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 compilao cruzada, target , host e build argumentos so dadas. O prefixo tambm est definido para /usr , no 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 binrio no diretrio de compilao e depende do software que est sendo j est configurado (da a referncia ao .configured arquivo). Basicamente, ela executa make dentro do diretrio 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 binrio no diretrio 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 no tenta instalar o software no host /usr , mas sim no alvo /usr . Aps a instalao, o /usr/man diretrio dentro do sistema de arquivos-alvo removido para economizar espao. Linha 40 define o alvo principal do software - o que acabar por ser usado pelo nvel superior Makefile para fazer o download, compilar e, em seguida, instalar este pacote. Esta meta deve antes de tudo depende de todas as dependncias necessrias do software (no nosso exemplo uClibc, e ncurses) e tambm dependem do binrio final. Esta dependncia ltima vai chamar todas as dependncias anterior na ordem correta. Linha 42 define um alvo simples que s faz o download do cdigo fonte. Isto no usado durante a operao normal de BuildRoot, mas necessrio se voc pretende baixar todas as fontes necessrias a uma vez para construir mais tarde offline. Note que se voc adicionar um novo pacote, proporcionando uma libfoo-source alvo obrigatria para suporte a usurios que desejam fazer offline-constri. Alm disso, facilita a verificao se todas as fontes de pacotes so para download. Linhas 44-46 definir um alvo fcil de limpar o software construir chamando o Makefile com as opes apropriadas. O -clean alvo deve executar make clean em US $ (BUILD_DIR) / pacote-verso e deve desinstalar todos os arquivos do pacote de US $ (STAGING_DIR) e de $ (target_dir). Linhas 48-49 definir um alvo fcil de remover completamente o diretrio no qual o software foi descompactado, configurado e compilado. O -dirclean alvo deve completamente rm $ (BUILD_DIR) / pacote-verso. Linhas 51-58 adicionar o alvo libfoo lista de metas a serem compilados por BuildRoot, primeiro verificar se a opo de configurao para este pacote foi ativado usando a ferramenta de configurao. Se assim for, ento "subscreve" este pacote para ser compilado, adicionando o pacote para a varivel de metas globais. O nome adicionado ao METAS varivel global o nome do alvo este pacote, tal como definido na linha 40 , que usado por BuildRoot fazer o download, compilar e ento instalar este pacote.

Gettext integrao e interao com pacotes


Muitos pacotes que a internacionalizao apoio usar a biblioteca gettext. Dependncias para esta biblioteca bastante complicado e, portanto, merece uma explicao. O uClibc biblioteca C no 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 prpria gettext, e neste caso, a biblioteca gettext separados no deve ser compilado, porque cria vrios tipos de falhas de construo.

Alm disso, alguns pacotes (como libglib2) exigem gettext incondicionalmente, enquanto outros pacotes (aqueles que apiam --disable-nls em geral) s exigem gettext quando o suporte local ativado. Portanto, BuildRoot define duas opes de configurao: BR2_NEEDS_GETTEXT , o que verdade, logo que o conjunto de ferramentas no fornece a sua implementao gettext prpria BR2_NEEDS_GETTEXT_IF_LOCALE , o que verdade se o toolchain no fornece a sua implementao gettext prpria 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 tambm necessrio 2. Use $(if $(BR2_NEEDS_GETTEXT),gettext) no pacote de DEPENDENCIES varivel 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 tambm necessrio 2. Use $(if $(BR2_NEEDS_GETTEXT_IF_LOCALE),gettext) no pacote de DEPENDENCIES varivel

Concluso
Como voc pode ver, acrescentando um pacote de software para BuildRoot simplesmente uma questo de escrever um Makefile usando um exemplo existente e modific-lo de acordo com o processo de compilao exigidos pelo pacote. Se voc pacote de software que podem ser teis para outras pessoas, no se esquea de enviar um patch para os desenvolvedores BuildRoot!

Perguntas mais frequentes


O boot trava aps Starting network... module-init-tools no consegue construir com cannot find -lc

O boot trava aps Starting network...


Se o processo de inicializao parece travar aps as seguintes mensagens (mensagens no necessarly exatamente similar, dependendo da lista de pacotes selecionados):
Liberando memria init: 3972K Inicializando gerador de nmeros aleatrios ... feito. Comeando rede ... Comeando dropbear sshd: gerao de chaves rsa ... gerando chave dsa ...

OK

ento isso significa que seu sistema est rodando, mas no 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 configurao, 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 no consegue construir com cannot find -lc


Se a compilao do module-init-tools para o host falha com:
/ Usr / bin / ld: cannot find-lc

ento provavelmente voc est executando uma distribuio Fedora (ou similar), e voc deve instalar o glibc-static pacote. Isso ocorre porque o module-init-tools processo de construo 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/