Capítulo 4

Mudamos para novo endereço: http://sourceforge.net/projects/lfsptbr/

Obrigado!

********************

Essa semana foi longa, muito longa e trabalhosa.

Aconteceu muita coisa, desde um alagamento inexplicável em meu carro (tive que literalmente tirar água de dentro dele com um balde) até um acidente de trabalho com meu pai, o que exigiu minha atenção.

O alagamento no carro resultou em pane elétrica e fim da minha bateria que já estava pela hora da morte mesmo (=P), mas isso me tomou um tempo precioso.
Meu pai felizmente está totalmente recuperado do acidente e já voltou ao trbalho.
Felizmente tudo terminou bem. =D

Devido a essas e outras questões pessoais que não cabem no escopo desse projeto, só agora disponibilizo o Capítulo 4.

Segue o pdf: 05_LFS_pt_BR.pdf

Segue o texto:

*****

Capítulo 4. Preparações Finais

4.1. Sobre a variável $LFS

A variável de ambiente LFS será usada durante todo o livro. É imprescindível que esta variável sempre esteja definida. Ela deve ser configurada para indicar o ponto de montagem da partição LFS. Cheque se a variável LFS está configurada propriamente com o comando:

echo $LFS

Certifique-se que a saída mostra o caminho para o ponto de montagem da partição LFS, que seria /mnt/lfs caso o exemplo tenho sido seguido. Se a saída não estiver correta, a variável pode ser configurada com:

export LFS=/mnt/lfs

Ter essa variável configurada é útil uma vez que comandos como mkdir $LFS/tools podem ser digitados exatamente como apresentados no livro. O shell irá substituir automaticamente o “$LFS” por “/mnt/lfs” (ou com o qualquer outro valor atribuído a variável) quando ele processar a linha de comando.

Não esqueça de verificar se a variável $LFS está configurada quando você deixar ou retornar ao ambiente de trabalho ( quando se executa um su para entrar como root ou outro usuário).

4.2. Criando o diretório $LFS/tools

Todos os programas compilados no Capítulo 5 serão instalados no diretório $LFS/tools para mantê-los separados dos programas compilados no Capítulo 6. Os programas compilados aqui serão ferramentas temporárias e não serão parte do sistema LFS final. Mantendo esses programas em um diretório separado, eles podem facilmente ser descartados após seu uso. Isso também previne que esses programas terminem nos diretórios de produção do sistema anfitrião ( fácil de acontecer acidentalmente no Capítulo 5).

Crie os diretórios solicitado executando o comando seguinte como root:

mkdir -v $LFS/tools

O próximo passo é criar um link simbólico /tools no sistema anfitrião. Esse link vai apontar para o diretório recém-criado na partição LFS. Execute o comando como root:

ln -sv $LFS/tools /

Nota

O comando acima está correto. O comando ln tem algumas variações sintáticas, então certifique-se de checar info coreutils ln e ln(1) antes de reportar o que você pode achar que seja um erro.

O link simbólico criado habilita as ferramentas utilizadas na construção do sistema a serem compiladas de tal forma que sempre se faz referência a /tools, significando que o compilador, assembler e linker funcionarão tanto no Capítulo 5 ( quando nós ainda usaremos algumas ferramentas do sistema anfitrião) quanto no seguinte (quando nós mudaremos, chroot, para a partição LFS).

4.3. Adicionando o usuário LFS

Quando logado como usuário root, cometer um simples erro pode danificar ou destruir um sistema. Portanto, nós recomendamos construir os pacotes neste capítulo como um usuário sem privilégios. Você poderia usar seu próprio usuário, mas para facilitar a configuração de um ambiente de trabalho limpo, crie um novo usuário chamado lfs como um membro de um novo grupo (também chamado lfs) e use esse usuário durante o processo de instalação. Como root, execute os seguintes comandos para adicionar o novo usuário:

groupadd lfs

useradd -s /bin/bash -g lfs -m -k /dev/null lfs

O significado das opções do comando:

-s /bin/bash

Faz do bash o shell padrão para o usuário lfs.

-g lfs

Adiciona o usuário lfs ao grupo lfs.

-m

Esta opção cria um diretório de usuário (home) para o usuário lfs.

-k /dev/null

Esse parâmetro previne a possível cópia de arquivos do esqueleto de diretório (ou diretório esqueleto, cujo padrão é /etc/skel) mudando a localização de entrada para o dispositivo especial nulo (null).

lfs

Esse é o nome real para o grupo e usuário criados.

Para entrar como lfs (em oposição a mudar para o usuário lfs quando logado como root, o que não querer que o usuário lfs tenha uma senha), dê ao usuário lfs uma senha:

passwd lfs

Garanta ao usuário lfs acesso total ao diretório $LFS/tools fazendo o usuário lfs dono do diretório:

chown -v lfs $LFS/tools

Se um diretório de trabalho separado foi criado como sugerido, dê ao usuário lfs a posse do mesmo:

chown -v lfs $LFS/sources

Em seguida, entre como usuário lfs. Isso pode ser feito via terminal virtual, através de um gerenciador de tela, ou com o comando seguinte para mudança de usuário:

su – lfs

O “–“ instrui o comando su a iniciar um shell de login em vez de um shell non-login. A diferença entre esses dois tipos de shell pode ser encontrada em detalhes em bash(1) e info bash.

4.4. Configurando o Ambiente

Configure um bom ambiente de trabalho criando dois novos arquivos de inicialização para o shell bash. Enquanto logado como usuário lfs, execute o comando seguinte para criar um novo arquivo .bash_profile:

cat > ~/.bash_profile << "EOF"

exec env -i HOME=$HOME TERM=$TERM PS1='\u:\w\$ ' /bin/bash

EOF

Enquanto logado como usuário lfs, o shell inicial é geralmente o shell de login que lê o arquivo /etc/profile do sistema anfitrião (que provavelmente contém algumas configurações e variáveis de ambiente) e então lê o arquivo .bash_profile. O comando exec env -i.../bin/bash no arquivo .bash_profile substitui o shell em utilização por um novo com um ambiente completamente vazio, exceto pelas variáveis HOME, TERM e PS1. Isso garante que nenhuma variável de ambiente indesejável e potencialmente danosa do sistema anfitrião vaze para o listema em construção. A técnica usada aqui faz com que se alcance o objetivo de um ambiente limpo.

A nova instância do shell é um shell non-login, que não lê os arquivos /etc/profile e .bash_profile, mas lê o arquivo .bashrc. Crie o arquivo .bashrc agora:

cat > ~/.bashrc << "EOF"

set +h

umask 022

LFS=/mnt/lfs

LC_ALL=POSIX

LFS_TGT=$(uname -m)-lfs-linux-gnu

PATH=/tools/bin:/bin:/usr/bin

export LFS LC_ALL LFS_TGT PATH

EOF

O comando set +h desativa a função hash do bash. Geralmente “hashing” é uma característica útil – bash usa uma tabela hash (tabela de dispersão ou tabela de espalhamento) para lembrar o caminho completo de arquivos executáveis evitando procurar no PATH várias vezes pelo mesmo executável. Entretanto, as novas ferramentas devem ser usadas tão logo estejam instaladas. Desativando a função hasg, o shell vai sempre procurar no PATH quando um programa estiver para ser executado. Dessa forma, o shell encontrará as ferramentas recém compiladas em $LFS/tools tão logo elas estejam disponíveis sem lembrar da versão anterior dos mesmos programas que estavam em uma localização diferente.

Configurando a máscara de criação de arquivos do usuário (umask) para 022 garante que somente o dono dos arquivos e diretórios recém-criados tem poder de escrita, mas eles podem ser lidos e executados por qualquer um (assumindo que os modos padrão são usados pelas chamadas de sistema open(2), novos arquivos ficam com permissão 644 e diretórios com modo 755).

A variável LFS deve ser configurada para o ponto de montagem escolhido.

A variável LC_ALL controla a localização de certos programas, fazendo duas mensagens seguirem as convenções de um país específico. Se o sistema anfitrião usa uma Glibc mais velha que 2.2.4, ter LC_ALL configurado para qualquer coisa diferente de “POSIX” ou “C” (durante esse capítulo) pode causar problemas se você deixar o ambiente de trabalho de desejar retornar depois. Configurando LC_ALL para “POSIX” ou “C” (as duas são equivalentes) garante que tudo vai funcionar como esperado no ambiente de trabalho.

A variável LFS_TGT define uma descrição de máquina fora do padrão, mas compatível para uso quando construindo nosso compilador cruzado (cross compiler) e linker e quando usando os mesmos para compilação do conjunto de ferramentas para desenvolvimento (toolchain). Mais informações estão disponíveis na Seção 5.2, “Notas Técnicas sobre as ferramentas de desenvolvimento”.

Colocando /tools/bin antes do padrão no PATH, todos os programas instalados no Capítulo 5 são encontrados pelo shell imediatamente após sua instalação. Isso, combinado com a desativação do hashing, limita o risco de programas velhos do sistema anfitrião serem usados quando os mesmos programas estão disponíveis no ambiente do Capítulo 5.

Finalmente, para ter o ambiente totalmente preparado para construção das ferramentas temporárias, use o comando source no recém-criado aquivo .bash_profile:

source ~/.bash_profile

4.5. Sobre SBUs

Muitas pessoas gostariam de saber de antemão quanto tempo aproximadamente leva para compilar e instalar cada pacote. Devido ao fato do Linux From Scratch poder ser construído em vários sistemas diferentes, é impossível disponibilizar estimativas de tempo apuradas. O maior pacote (Glibc) levará aproximadamente 20 minutos em sistemas mais rápidos, mas poderia levar até 3 dias em sistemas mais lentos! Em vez de disponibilizar tempos, a unidade de medida padrão de construção SBU (Standard Build Unit) será usada.

A unidade SBU será usada como se segue. O primeiro pacote a ser compilado neste livro é Binutils no Capítulo 5. O tempo necessário para compilar esse pacote é que será referência como SBU. Todos os outros tempos de compilação serão expressos relativamente a esse tempo.

Por exemplo, considere um pacote cujo tempo de compilação é 4.5 SBUs. Isso significa que se um sistema precisou de 10 minutos para compilar e instalar a primeira passagem do Binutils, será necessário aproximadamente 45 minutos para construir esse pacote exemplo. Felizmente, a maioria dos tempos de construção são menores do que o tempo para o Binutils.

De maneira geral, SBUs não são totalmente acuradas porque dependem de muitos fatores, incluindo a versão do GCC do sistema anfitrião. Elas são disponibilizadas aqui para dar uma estimativa de quanto tempo pode levar para instalar um pacote, mas os números podem varia por dúzias de minutos em alguns casos.

Para ver o tempo real para algumas máquinas específicas, nós recomendamos The LinuxFromScratch SBU Home Page no endereço http://www.linuxfromscratch.org/~sbu/.

Nota

Para muitos sistemas modernos com múltiplos processadores (ou cores) o tempo de compilação para um pacote pode ser reduzido usando um “parallel make”, o que pode ser feito tanto configurando uma variável de ambiente ou dizendo para o programa make quantos processadores estão disponíveis. For exemplo, um Core2Duo pode suportar dois processos simultâneos com:

export MAKEFLAGS='-j 2'

ou só construindo com:

make -j2

Quando múltiplos processadores são usados dessa maneira, as unidades SBU no livro irão variar mais do que normalmente aconteceria. Analisando a saída dos processos de construção também será mais difícil porque as linhas dos diferentes processos estarão intercaladas. Se você tiver problemas com uma passagem durante a construção, retorne para um único processador para analisar devidamente as mensagens de erro.

4.6. Sobre as Ferramentas de Teste (Suites de Teste)

A maioria dos pacotes disponibiliza ferramentas de teste. Rodas as ferramentas de teste para um pacote recém construído é uma boa ideia porque isso pode prover um “cheque de sanidade” indicando que tudo foi devidamente compilado. Uma ferramenta de testes que executa seu conjunto de checagens geralmente prova que o pacote está funcionando como o desenvolvedor pretendia. Entretanto isso não garante que o pacote está totalmente livre de bugs.

Algumas suites de teste são mais importantes que outras. Por exemplo, as suites de teste para os pacotes principais das ferramentas de desenvolvimento (toolchain) – GCC, Binutils e Glibc – são de máxima importância devido a seu papel central em um sistema que funcione corretamente. As suites de teste para GCC e Glibc podem levar bastante tempo para completarem, especialmente em uma máquina lenta, mas são fortemente recomendadas.

Nota

Experiência tem mostrado que há pouco a se ganhar executando as suites de teste no Capítulo 5. Não há escapatória ao fato de que o sistema anfitrião sempre exerce alguma influência sobre os testes naquele capítulo, geralmente causando falhas inexplicáveis. Devido ao fato das ferramentas construídas no Capítulo 5 serem temporárias e eventualmente descartadas, nós não recomendamos executar as suites de teste no Capítulo 5 para a maioria dos leitores. As instruções para a execução dessas suites de testes são disponibilizadas para beneficiar os desenvolvedores e analistas (testers), mas elas são opcionais.

Um problema comum enquanto executando as suites de teste para Binutils e GCC é ficar sem pseudo terminais (PTYs). Isso pode resultar em um alto número de testes com falhas. Isso pode acontecer por diversos motivos, mas a causa mais provável é que o sistema anfitrião não tem os arquivos de sistema devpts configurados corretamente. Esse problema é discutido em maiores detalhes na página http://www.linuxfromscratch.org//lfs/faq.html#no-ptys.

Algumas vezes suites de testes falham, mas por razões das quais os desenvolvedores estão cientes e não são consideradas críticas. Consulte os registros (logs) localizados em http://www.linuxfromscratch.org/lfs/build-logs/7.3/ para verificar quando essas falhas são esperadas ou não. Este site é válido para todos os testes durante este livro.

*****
Até o próximo!