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!
