Notas técnicas do conjunto de ferramentas do Linux from Scratch por OnWorks

Ir para o conteúdo

5.2 Notas técnicas do conjunto de ferramentas‌

Esta seção explica alguns dos fundamentos e detalhes técnicos por trás do método geral de construção. Não é essencial entender imediatamente tudo nesta seção. A maioria dessas informações ficará mais clara após a execução de uma compilação real. Esta seção pode ser consultada a qualquer momento durante o processo.

imagem

O objetivo geral do Capítulo 5 é produzir uma área temporária que contenha um conjunto de ferramentas em boas condições que possa ser isolado do sistema host. Usando chroot, os comandos nos capítulos restantes estarão contidos naquele ambiente, garantindo uma compilação limpa e sem problemas do sistema LFS de destino. O processo de construção foi projetado para minimizar os riscos para novos leitores e fornecer o maior valor educacional ao mesmo tempo.

Note

Antes de continuar, esteja ciente do nome da plataforma de trabalho, geralmente chamada de trio de destino. Uma maneira simples de determinar o nome do trio alvo é executar o config.palpite script que vem com o código-fonte de muitos pacotes. Descompacte os fontes do Binutils e execute o script: ./config.guess e observe a saída. Por exemplo, para um processador Intel de 32 bits, a saída será i686-pc-linux-gnu. Em um sistema de 64 bits, será x86_64-pc-linux-gnu.

Também esteja ciente do nome do vinculador dinâmico da plataforma, muitas vezes referido como o carregador dinâmico (não deve ser confundido com o vinculador padrão ld que faz parte do Binutils). O vinculador dinâmico fornecido pelo Glibc encontra e carrega as bibliotecas compartilhadas necessárias para um programa, prepara o programa para ser executado e, em seguida, o executa. O nome do vinculador dinâmico para uma máquina Intel de 32 bits será ld-linux.so.2 (ld-linux-x86-64.so.2 para sistemas de 64 bits). Uma maneira infalível de determinar o nome do vinculador dinâmico é inspecionar um binário aleatório do sistema host executando: readelf -l | intérprete grep e observando a saída. A referência oficial cobrindo todas as plataformas está no versões shlib arquivo na raiz da árvore de origem do Glibc.

Note

Antes de continuar, esteja ciente do nome da plataforma de trabalho, geralmente chamada de trio de destino. Uma maneira simples de determinar o nome do trio alvo é executar o config.palpite script que vem com o código-fonte de muitos pacotes. Descompacte os fontes do Binutils e execute o script: ./config.guess e observe a saída. Por exemplo, para um processador Intel de 32 bits, a saída será i686-pc-linux-gnu. Em um sistema de 64 bits, será x86_64-pc-linux-gnu.

Também esteja ciente do nome do vinculador dinâmico da plataforma, muitas vezes referido como o carregador dinâmico (não deve ser confundido com o vinculador padrão ld que faz parte do Binutils). O vinculador dinâmico fornecido pelo Glibc encontra e carrega as bibliotecas compartilhadas necessárias para um programa, prepara o programa para ser executado e, em seguida, o executa. O nome do vinculador dinâmico para uma máquina Intel de 32 bits será ld-linux.so.2 (ld-linux-x86-64.so.2 para sistemas de 64 bits). Uma maneira infalível de determinar o nome do vinculador dinâmico é inspecionar um binário aleatório do sistema host executando: readelf -l | intérprete grep e observando a saída. A referência oficial cobrindo todas as plataformas está no versões shlib arquivo na raiz da árvore de origem do Glibc.

Alguns pontos técnicos importantes de como o método de construção do Capítulo 5 funciona:

• Ajustando ligeiramente o nome da plataforma de trabalho, alterando o trio de alvo de campo "fornecedor" por meio do LFS_TGT variável, garante que a primeira compilação de Binutils e GCC produz um cross-linker e cross-compilador compatível. Em vez de produzir binários para outra arquitetura, o cross-linker e o cross-compiler produzirão binários compatíveis com o hardware atual.

• As bibliotecas temporárias são compiladas cruzadas. Como um compilador cruzado por natureza não pode depender de nada de seu sistema host, esse método remove a contaminação potencial do sistema de destino, diminuindo a chance de cabeçalhos ou bibliotecas do host serem incorporados às novas ferramentas. A compilação cruzada também permite a possibilidade de construir bibliotecas de 32 e 64 bits em hardware compatível com 64 bits.

• A manipulação cuidadosa da origem do GCC informa ao compilador qual vinculador dinâmico de destino será usado.

Binutils é instalado primeiro porque o configurar execuções de GCC e Glibc realizam vários testes de recursos no assembler e no linker para determinar quais recursos de software devem ser habilitados ou desabilitados. Isso é mais importante do que se possa imaginar. Um GCC ou Glibc configurado incorretamente pode resultar em um conjunto de ferramentas sutilmente quebrado, onde o impacto de tal quebra pode não aparecer até perto do final da construção de uma distribuição inteira. Uma falha de suíte de teste geralmente destacará este erro antes que muito trabalho adicional seja executado.

Binutils instala seu montador e linker em dois locais, / tools / bin e / tools / $ LFS_TGT / bin. As ferramentas em um local estão fortemente vinculadas a outro. Uma faceta importante do vinculador é sua ordem de pesquisa na biblioteca. Informações detalhadas podem ser obtidas em ld passando por --verbose bandeira. Por exemplo, um ld --verbose | PESQUISA grep irá ilustrar os caminhos de pesquisa atuais e sua ordem. Mostra quais arquivos estão vinculados por ld compilando um programa fictício e passando o --verbose mude para o vinculador. Por exemplo, gcc dummy.c -Wl, - verbose 2> & 1

| grep bem sucedido irá mostrar todos os arquivos abertos com sucesso durante a vinculação.

O próximo pacote instalado é o GCC. Um exemplo do que pode ser visto durante sua execução de configurar é:

verificando qual assembler usar ... / tools / i686-lfs-linux-gnu / bin / as verificando qual linker usar ... / tools / i686-lfs-linux-gnu / bin / ld

Isso é importante pelas razões mencionadas acima. Também demonstra que o script de configuração do GCC não pesquisa os diretórios PATH para encontrar quais ferramentas usar. No entanto, durante a operação real de gcc em si, os mesmos caminhos de pesquisa não são necessariamente usados. Para descobrir qual linker padrão gcc irá usar, executar: gcc -print-prog-name = ld.

Informações detalhadas podem ser obtidas em gcc passando por -v opção de linha de comando durante a compilação de um programa fictício. Por exemplo, gcc -v manequim.c mostrará informações detalhadas sobre os estágios de pré-processador, compilação e montagem, incluindo gccinclui caminhos de pesquisa e sua ordem.

Em seguida, são instalados os cabeçalhos de API do Linux limpos. Isso permite que a biblioteca C padrão (Glibc) faça interface com os recursos que o kernel do Linux fornecerá.

O próximo pacote instalado é o Glibc. As considerações mais importantes para construir o Glibc são o compilador, as ferramentas binárias e os cabeçalhos do kernel. O compilador geralmente não é um problema, pois Glibc sempre usará o compilador relacionado ao --hospedeiro parâmetro passado para seu script de configuração; por exemplo, em nosso caso, o compilador será i686-lfs-linux-gnu-gcc. As ferramentas binárias e os cabeçalhos do kernel podem ser um pouco mais complicados. Portanto, não corra riscos e use as opções de configuração disponíveis para aplicar as seleções corretas. Após a corrida de configurar, verifique o conteúdo do config.make arquivo no glibc-build diretório para todos os detalhes importantes. Observe o uso de CC = "i686-lfs-gnu-gcc" para controlar quais ferramentas binárias são usadas e o uso do -nostdinc e -isistema sinalizadores para controlar o caminho de pesquisa de inclusão do compilador. Esses itens destacam um aspecto importante do pacote Glibc - é muito autossuficiente em termos de seu maquinário de construção e geralmente não depende dos padrões do conjunto de ferramentas.

Durante a segunda passagem do Binutils, podemos utilizar o --com-lib-caminho configure a chave para controlar ldcaminho de pesquisa da biblioteca de.

Para a segunda passagem do GCC, suas fontes também precisam ser modificadas para informar ao GCC para usar o novo vinculador dinâmico. Caso contrário, os próprios programas GCC terão o nome do vinculador dinâmico do sistema host / lib diretório embutido neles, o que anularia o objetivo de ficar longe do host. Deste ponto em diante, o conjunto de ferramentas principal é independente e auto-hospedado. O restante dos pacotes do Capítulo 5 são todos construídos contra o novo Glibc em /Ferramentas.

Ao entrar no ambiente chroot no Capítulo 6, o primeiro pacote principal a ser instalado é o Glibc, devido à sua natureza autossuficiente mencionada acima. Uma vez que este Glibc é instalado em / usr, faremos uma rápida mudança dos padrões do conjunto de ferramentas e, em seguida, continuaremos construindo o restante do sistema LFS de destino.