O sistema LFS será construído usando uma distribuição Linux já instalada (tal como Debian; o OpenMandriva; Fedora ou openSUSE). Esse sistema Linux existente (o anfitrião) será usado como um ponto de partida para fornecer os aplicativos necessários, incluindo um compilador, um vinculador e um shell para construir o novo sistema. Selecione a opção “desenvolvimento” durante a instalação da distribuição para incluir essas ferramentas.

Como uma alternativa a instalar uma distribuição separada em sua máquina, você possivelmente deseje usar um LiveCD de uma distribuição comercial.

O Capítulo 2 deste livro descreve como criar uma nova partição Linux nativa e sistema de arquivos, onde o novo sistema LFS será compilado e instalado. O Capítulo 3 explica quais pacotes e patches precisam ser baixados para construir um sistema LFS e como armazená-los no novo sistema de arquivos. O Capítulo 4 discute a configuração de um ambiente de trabalho apropriado. Por favor, leia o Capítulo 4 cuidadosamente, uma vez que ele explica vários assuntos importantes a respeito dos quais você deveria estar ciente antes de começar seu trabalho ao longo do Capítulo 5 e além.

O Capítulo 5, explica a instalação do conjunto inicial de ferramentas, (binutils, gcc e glibc) usando técnicas de compilação cruzada para isolar as novas ferramentas das do sistema anfitrião.

O Capítulo 6 te mostra como compilar cruzadamente utilitários básicos usando o recém construído conjunto cruzado de ferramentas.

O Capítulo 7 então entra em um ambiente "chroot" onde nós usamos as novas ferramentas para construir todos o restante das ferramentas necessárias para criar o sistema LFS.

Esse esforço para isolar o sistema novo do sistema anfitrião possivelmente pareça excessivo. Uma explicação técnica completa do porquê isso é feito é fornecida nas Observações Técnicas do Conjunto de Ferramentas.

No Capítulo 8, o sistema LFS completo é construído. Outra vantagem fornecida pelo ambiente chroot é a de que ele te permite continuar usando o sistema anfitrião enquanto o LFS está sendo construído. Enquanto espera por compilações de pacotes completarem, você pode continuar usando seu computador normalmente.

Para finalizar a instalação, a configuração básica do sistema é concluída no Capítulo 9, e o núcleo e carregador de inicialização são criados no Capítulo 10. O Capítulo 11 contém informação sobre como continuar a experiência LFS além deste livro. Após os passos neste capítulo terem sido implementados, o computador estará pronto para reinicializar no novo sistema LFS.

Esse é o processo em poucas palavras. Informação detalhada sobre cada passo é apresentada nos capítulos seguintes. Itens que pareçam complicados agora serão esclarecidos e tudo ficará em seu devido lugar conforme você embarcar na aventura do LFS.

Aqui está uma lista dos pacotes atualizados desde o lançamento anterior do LFS.

Esta é a versão 12.2 do livro Linux From Scratch, datada de 1º de setembro de 2024. Se este livro for mais antigo que seis meses, uma versão mais nova e melhor provavelmente já está disponível. Para descobrir, por favor verifique um dos espelhos via https://www.linuxfromscratch.org/mirrors.html.

Abaixo está uma lista das mudanças feitas desde o lançamento anterior do livro.

Se um problema ou uma pergunta for encontrado durante o trabalho ao longo deste livro, [então], por favor, verifique a página de Perguntas Frequentes em https://www.linuxfromscratch.org/faq/#generalfaq. Perguntas frequentemente já estão respondidas lá. Se sua pergunta não estiver respondida nessa página, [então], por favor, tente encontrar a origem do problema. A dica seguinte te dará alguma orientação com relação à resolução de problemas: https://www.linuxfromscratch.org/hints/downloads/files/errors.txt.

Se você não conseguir achar seu problema listado nas Perguntas Frequentes, [então] procure nas listas de discussão em https://www.linuxfromscratch.org/search.html.

Nós também temos uma comunidade LFS maravilhosa que está disposta a oferecer assistência por meio das listas de discussão e IRC (veja a seção Seção 1.4, “Recursos” deste livro). Entretanto, nós temos várias perguntas de suporte todos os dias e muitas delas poderiam ter sido facilmente respondidas indo para as Perguntas Frequentes ou procurando nas listas de discussão primeiro. Então, para que nós possamos oferecer a melhor assistência possível, você deveria primeiro fazer alguma pesquisa por conta própria. Isso nos permite focar nas necessidades menos usuais de suporte. Se suas buscas não produzirem uma solução, [então], por favor, inclua todas as informações relevantes (mencionadas abaixo) no seu pedido por ajuda.

gcc -D ALIASPATH=\"/mnt/lfs/usr/share/locale:.\"
-D LOCALEDIR=\"/mnt/lfs/usr/share/locale\"
-D LIBDIR=\"/mnt/lfs/usr/lib\"
-D INCLUDEDIR=\"/mnt/lfs/usr/include\" -D HAVE_CONFIG_H -I. -I.
-g -O2 -c getopt1.c
gcc -g -O2 -static -o make ar.o arscan.o commands.o dir.o
expand.o file.o function.o getopt.o implicit.o job.o main.o
misc.o read.o remake.o rule.o signame.o variable.o vpath.o
default.o remote-stub.o version.o opt1.o
-lutil job.o: In function `load_too_high':
/lfs/tmp/make-3.79.1/job.c:1565: undefined reference
to `getloadavg'
collect2: ld returned 1 exit status
make[2]: *** [make] Error 1
make[2]: Leaving directory `/lfs/tmp/make-3.79.1'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/lfs/tmp/make-3.79.1'
make: *** [all-recursive-am] Error 2

make [2]: *** [make] Error 1

Neste capítulo, as ferramentas do anfitrião necessárias para a construção do LFS são verificadas e, se necessário, instaladas. Então uma partição que hospedará o sistema LFS é preparada. Nós criaremos a própria partição, criaremos um sistema de arquivos nela e a montaremos.

O LFS é projetado para ser construído em uma sessão. Isto é, as instruções assumem que o sistema não será desligado durante o processo. Isso não significa que o sistema tenha de ser construído de uma vez só. O problema é que certos procedimentos precisam ser repetidos depois de uma inicialização quando se retomando o LFS em pontos diferentes.

Como a maior parte dos outros sistemas operacionais, o LFS geralmente é instalado em uma partição dedicada. A abordagem recomendada para construir um sistema LFS é a de usar uma partição disponível vazia ou, se você tiver espaço suficiente não particionado, criar uma.

Um sistema mínimo exige uma partição com cerca de dez (10) gigabytes (GB). Isso é suficiente para armazenar todos os tarballs dos fontes e compilar os pacotes. Entretanto, se o sistema LFS for concebido para ser o sistema Linux principal, [então] aplicativos adicionais provavelmente serão instalados os quais exigirão espaço adicional. Uma partição de trinta (30) GB é um tamanho razoável para permitir o crescimento. O sistema LFS em si não ocupará esse espaço todo. Uma boa parte dessa exigência é para fornecer armazenamento temporário livre suficiente. Adicionalmente, a compilação de pacotes pode exigir um monte de espaço de disco que será recuperado após o pacote ser instalado.

Como nem sempre existe Memória de Acesso Aleatório (RAM) suficiente disponível para processos de compilação, é uma boa ideia usar uma pequena partição de disco como espaço de swap. Ele é usado pelo kernel para armazenar dados raramente usados e deixa mais memória disponível para processos ativos. A partição de swap para um sistema LFS pode ser a mesma que aquela usada pelo sistema anfitrião, caso no qual não é necessário criar outra.

Inicie um aplicativo de particionamento de disco como o "cfdisk" ou o "fdisk" com uma opção de linha de comando indicando o disco rígido no qual a nova partição será criada—por exemplo "/dev/sda" para a unidade primária de disco. Crie uma partição nativa do "Linux" e uma partição "swap", se necessária. Por favor, recorra a "cfdisk(8)" ou a "fdisk(8)" se você ainda não sabe como usar os aplicativos.

Lembre-se da designação da nova partição (por exemplo, sda5). Este livro se referirá a essa como a partição do LFS. Lembre-se também da designação da partição swap. Esses nomes serão necessários posteriormente para o arquivo /etc/fstab.

Uma partição é apenas um intervalo de setores em uma unidade de disco, delimitados por fronteiras configuradas em uma tabela de partição. Antes do sistema operacional conseguir usar uma partição para armazenar quaisquer arquivos, a partição precisa estar formatada para conter um sistema de arquivos, tipicamente consistindo de um rótulo, blocos de diretório, blocos de dados e um esquema de indexação para localizar um arquivo em particular mediante demanda. O sistema de arquivos também auxilia o SO a manter rastreio do espaço livre na partição; reservar os setores necessários quando um arquivo novo for criado ou um arquivo existente for estendido; e reciclar os segmentos de dados livres criados quando arquivos são deletados. Possivelmente também forneça suporte para redundância de dados e para recuperação dos erros.

O LFS consegue usar qualquer sistema de arquivos reconhecido pelo kernel Linux, mas os tipos mais comuns são ext3 e ext4. A escolha do sistema de arquivos certo pode ser complexa; depende das características dos arquivos e do tamanho da partição. Por exemplo:

Outros sistemas de arquivos, incluindo FAT32, NTFS, JFS e XFS são úteis para propósitos especializados. Mais informação a respeito desses sistemas de arquivos, e de muitos outros, pode ser encontrada em https://en.wikipedia.org/wiki/Comparison_of_file_systems.

O LFS assume que o sistema de arquivos raiz (/) é do tipo ext4. Para criar um sistema de arquivos ext4 na partição do LFS, emita o seguinte comando:

mkfs -v -t ext4 /dev/<xxx>

Substitua <xxx> pelo nome da partição do LFS.

Se você estiver usando uma partição swap existente, [então] não há necessidade de formatá-la. Se uma nova partição swap foi criada, [então] ela precisará ser inicializada com este comando:

mkswap /dev/<yyy>

Substitua <yyy> pelo nome da partição swap.

Ao longo deste livro, a variável de ambiente LFS será usada muitas vezes. Você deveria se assegurar de que essa variável sempre está definida no decorrer do processo de construção do LFS. Ela deveria ser configurada para o nome do diretório onde você estará construindo seu sistema LFS - nós usaremos /mnt/lfs como um exemplo, porém você possivelmente escolha qualquer nome de diretório que queira. Se você está construindo o LFS em uma partição separada, [então] esse diretório será o ponto de montagem para a partição. Escolha um local de diretório e configure a variável com o seguinte comando:

export LFS=/mnt/lfs

Ter essa variável configurada é benéfico naqueles comandos, tais como mkdir -v $LFS/tools, que podem ser digitados literalmente. O shell automaticamente substituirá “$LFS” por “/mnt/lfs” (ou para o que a variável foi configurada) quando processar a linha de comando.

echo $LFS

Agora que um sistema de arquivos tenha sido criado, a partição precisa ser montada, de forma que o sistema anfitrião consiga acessá-la. Este livro presume que o sistema de arquivos esteja montado no diretório especificado pela variável de ambiente LFS descrita na seção anterior.

Estritamente falando, ninguém consegue “montar uma partição”. A pessoa monta o sistema de arquivos embutido naquela partição. Porém, dado que uma partição não pode conter mais que um sistema de arquivos, as pessoas frequentemente falam da partição e do sistema de arquivos associado como se fossem um e o mesmo.

Crie o ponto de montagem e monte o sistema de arquivos do LFS com estes comandos:

mkdir -pv $LFS
mount -v -t ext4 /dev/<xxx> $LFS

Substitua <xxx> pelo nome da partição do LFS.

Se estiver usando múltiplas partições para o LFS (por exemplo, uma para / e outra para /home), [então] monte-as como isto:

mkdir -pv $LFS
mount -v -t ext4 /dev/<xxx> $LFS
mkdir -v $LFS/home
mount -v -t ext4 /dev/<yyy> $LFS/home

Substitua <xxx> e <yyy> pelos nomes apropriados das partições.

Assegure-se de que essa nova partição não esteja montada com permissões que sejam restritivas demais (tais como as opções nosuid ou nodev). Execute o comando mount sem quaisquer parâmetros para ver quais opções estão configuradas para a partição do LFS montada. Se nosuid e (ou) nodev estiverem configuradas, [então] a partição precisa ser remontada.

/dev/<xxx>  /mnt/lfs ext4   defaults      1     1

Se você estiver usando uma partição swap, [então] assegure-se de que ela está habilitada usando o comando swapon:

/sbin/swapon -v /dev/<zzz>

Substitua <zzz> pelo nome da partição swap.

Agora que a nova partição do LFS está aberta para negócios, é tempo de baixar os pacotes.

Este capítulo inclui uma lista de pacotes que precisam ser baixados para a finalidade de construir um sistema Linux básico. Os números de versão listados correspondem a versões dos aplicativos que são conhecidos por funcionar e este livro é baseado no uso deles. Nós recomendamos veementemente contra o uso de versões diferentes, pois os comandos de construção para uma versão possivelmente não funcionem com uma versão diferente, a menos que a versão diferente seja especificada por uma errata do LFS ou conselho de segurança. As versões mais novas de pacote possivelmente também tenham problemas que exijam contornos. Esses contornos serão desenvolvidos e estabilizados na versão de desenvolvimento do livro.

Para alguns pacotes, o tarball de lançamento e o tarball instantâneo de repositório (Git ou SVN) para aquele lançamento possivelmente seja publicado com nomes de arquivo semelhantes. Um tarball de lançamento contém arquivos generalizados (por exemplo, um script configure gerado pelo autoconf), em adição ao conteúdo do correspondente instantâneo de repositório. O livro usa tarballs de lançamento sempre que possível. Usar um instantâneo de repositório em vez de um tarball de lançamento especificado pelo livro causará problemas.

Os locais das transferências possivelmente não estejam sempre acessíveis. Se um local de transferência tiver mudado desde quando este livro foi publicado, [então] o Google (http://www.google.com/) fornece um motor de busca útil para a maioria dos pacotes. Se essa busca for mal sucedida, [então] tente um dos meios alternativos de transferência em https://www.linuxfromscratch.org/lfs/mirrors.html#files.

Os pacotes e os remendos baixados precisarão ser armazenados em algum lugar que esteja convenientemente disponível durante a construção inteira. Um diretório de trabalho também é exigido para desempacotar os fontes e construí-los. $LFS/sources pode ser usado, tanto como o lugar para armazenar os tarballs e os remendos, quanto como um diretório de trabalho. Usando esse diretório, os elementos exigidos estarão localizados na partição do LFS e estarão disponíveis durante todos os estágios do processo de construção.

Para criar esse diretório, execute o seguinte comando, como usuária(o) root, antes de começar a sessão de transferência:

mkdir -v $LFS/sources

Torne esse diretório gravável e "sticky". “Sticky” significa que, mesmo se múltiplas(os) usuárias(os) tenham permissão de escrita, só a(o) dona(o) de um arquivo pode deletar o arquivo dentro de um diretório sticky. O seguinte comando habilitará os modos escrita e sticky:

chmod -v a+wt $LFS/sources

Existem muitas maneiras para obter todos os pacotes e remendos necessários para construir o LFS:

Para transferir todos os pacotes e os remendos usando a wget-list-sysv como uma entrada gerada para o comando wget, use:

wget --input-file=wget-list-sysv --continue --directory-prefix=$LFS/sources

Adicionalmente, começando com o LFS-7.0, existe um arquivo separado, md5sums, que pode ser usado para verificar se todos os pacotes corretos estão disponíveis antes de prosseguir. Coloque aquele arquivo em $LFS/sources e execute:

pushd $LFS/sources
  md5sum -c md5sums
popd

Essa verificação pode ser usada após recuperar os arquivos necessários com qualquer dos métodos listados acima.

Se os pacotes e os remendos forem transferidos como um(a) usuário(a) não root, [então] esses arquivos serão de propriedade do(a) usuário(a). O sistema de arquivos registra o(a) proprietário(a) pelo UID dele(a) e o UID de um(a) usuário(a) normal na distribuição anfitriã não é atribuído no LFS. Assim, os arquivos serão deixados de propriedade de um UID sem nome no sistema LFS final. Se você não atribuirá o mesmo UID para o(a) seu(ua) usuário(a) no sistema LFS, [então] mude os proprietários(as) desses arquivos para root agora para evitar esse problema:

chown root:root $LFS/sources/*

Transfira ou de outra forma obtenha os seguintes pacotes:

Tamanho total desses pacotes: cerca de NaN Mo

Adicionalmente aos pacotes, vários remendos também são exigidos. Esses remendos corrigem alguns erros nos pacotes que deveriam ser consertados pelo(a) Mantenedor(a). Os remendos também fazem pequenas modificações para tornar os pacotes mais fáceis de se trabalhar. Os seguintes remendos serão necessários para construir um sistema LFS:

Tamanho total desses remendos: cerca de NaN Mo

Adicionalmente aos remendos exigidos acima, existe um número de remendos opcionais criados pela comunidade do LFS. Esses remendos opcionais solucionam problemas menores ou habilitam funcionalidade que não está habilitada por padrão. Sinta-se à vontade para examinar a base de dados dos remendos localizada em https://www.linuxfromscratch.org/patches/downloads/ e adquirir quaisquer remendos adicionais para atender às necessidades do seu sistema.

Neste capítulo, nós realizaremos umas poucas tarefas adicionais para preparar para a construção do sistema temporário. Nós criaremos um conjunto de diretórios em $LFS (no qual instalaremos as ferramentas temporárias); adicionaremos uma(m) usuária(o) desprivilegiada(o); e criaremos um ambiente apropriado de construção para aquela(e) usuária(o). Nós também explicaremos as unidades de tempo “UPCs” que usamos para medir quanto tempo leva para construir od pacotes do LFS e forneceremos alguma informação acerca de suítes de teste de pacote.

Nesta seção, nós começamos povoando o sistema de arquivos do LFS com os lugares que constituirão o sistema Linux final. O primeiro passo é o de criar uma hierarquia limitada de diretório, de forma que os aplicativos compilados no Capítulo 6 (bem como a glibc e a libstdc++ no Capítulo 5) possam ser instalados no local final deles. Nós fazemos isso, de forma que aqueles aplicativos temporários sejam sobrescritos quando as versões finais sejam reconstruídas no Capítulo 8.

Crie o layout exigido de diretório emitindo os seguintes comandos como root:

mkdir -pv $LFS/{etc,var} $LFS/usr/{bin,lib,sbin}

for i in bin lib sbin; do
  ln -sv usr/$i $LFS/$i
done

case $(uname -m) in
  x86_64) mkdir -pv $LFS/lib64 ;;
esac

Os aplicativos no Capítulo 6 serão compilados com um compilador cruzado (mais detalhes podem ser encontrados na seção Observações Técnicas do Conjunto de Ferramentas). Esse compilador cruzado será instalado em um diretório especial, para separá-lo de outros aplicativos. Ainda atuando como root, crie esse diretório com este comando:

mkdir -pv $LFS/tools

Enquanto logada(o) como usuária(o) root, cometer um simples erro pode danificar ou destruir um sistema. Portanto, os pacotes nos próximos dois capítulos são construídos como uma(m) usuária(o) sem privilégios. Você poderia usar seu próprio nome de usuária(o), mas para tornar mais fácil configurar um ambiente de trabalho limpo, nós criaremos um(a) usuário(a) novo(a) chamado(a) lfs como um(a) membro(a) de um novo grupo (também chamado lfs) e executar comandos como lfs durante o processo de instalação. Como root, emita os seguintes comandos para adicionar a(o) novo(a) usuário(a):

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

Se quiser logar como lfs ou alternar para lfs a partir de um(a) usuário(a) não root (em oposição a alternar para o(a) usuário(a) lfs quando estiver logado(a) como root, o que não exige que o(a) usuário(a) lfs tenha uma senha), [então] você precisa configurar uma senha para lfs. Emita o seguinte comando como o(a) usuário(a) root para configurar a senha:

passwd lfs

Conceda a lfs acesso total a todos os diretórios sob $LFS tornando lfs a(o) dona(o) do diretório:

chown -v lfs $LFS/{usr{,/*},lib,var,etc,bin,sbin,tools}
case $(uname -m) in
  x86_64) chown -v lfs $LFS/lib64 ;;
esac

Em seguida, inicie um shell executando como usuária(o) lfs. Isso pode ser feito logando-se como lfs em um console virtual ou com o seguinte comando de substituir/alternar usuária(o):

su - lfs

O “-” instrui "su" a iniciar um "shell" de "login" em vez de um "shell" de não "login". A diferença entre esses dois tipos de "shells" está descrita em detalhes em "bash(1)" e "info bash".

Configure um bom ambiente de trabalho criando dois novos arquivos de inicialização para o shell bash. Enquanto logada(o) como usuária(o) lfs, emita o seguinte comando para criar um novo .bash_profile:

cat > ~/.bash_profile << "EOF"
exec env -i HOME=$HOME TERM=$TERM PS1='\u:\w\$ ' /bin/bash
EOF

Enquanto logada(o) como usuária(o) lfs ou quando alternado para o(a) usuário(a) lfs usando um comando su com a opção “-”, o shell inicial é um shell de login que lê o /etc/profile do anfitrião (provavelmente contendo algumas configurações e variáveis de ambiente) e então .bash_profile. O comando exec env -i.../bin/bash no arquivo .bash_profile substitui o shell em execuçã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 indesejada e potencialmente danosa oriunda do sistema anfitrião vaze para o ambiente de construção.

A nova instância do shell é um shell de não-login, que não lê, e executa, o conteúdo dos arquivos /etc/profile ou .bash_profile, porém, ao invés, lê, e executa, 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=/usr/bin
if [ ! -L /bin ]; then PATH=/bin:$PATH; fi
PATH=$LFS/tools/bin:$PATH
CONFIG_SITE=$LFS/usr/share/config.site
export LFS LC_ALL LFS_TGT PATH CONFIG_SITE
EOF

[ ! -e /etc/bash.bashrc ] || mv -v /etc/bash.bashrc /etc/bash.bashrc.NOUSE

Para muitos sistemas modernos com múltiplos processadores (ou núcleos), o tempo de compilação para um pacote pode ser reduzido executando-se um "make paralelo", informando-se ao aplicativo "make" quantos processadores estão disponíveis por meio de uma opção de linha de comando ou de uma variável de ambiente. Por exemplo, um processador "Intel" "Core i9-13900K" tem oito (08) núcleos "D" (desempenho) e dezesseis (16) núcleos "E" (eficiência), e um núcleo "D" consegue executar simultaneamente duas camadas, de forma que cada núcleo "D" seja modelado como dois núcleos lógicos pelo núcleo Linux. Como resultado, existem trinta e dois (32) núcleos lógicos no total. Uma maneira óbvia de usar todos esses núcleos lógicos é a de permitir que o "make" gere até trinta e duas (32) tarefas de construção. Isso pode ser feito passando-se a opção "-j32" para o "make":

make -j32

Ou configure a variável de ambiente "MAKEFLAGS" e o conteúdo dela será usado automaticamente por "make" como opções de linha de comando:

export MAKEFLAGS=-j32

Para usar todos os núcleos lógicos disponíveis para construir pacotes em "Capítulo 5" e "Capítulo 6", configure "MAKEFLAGS" agora em ".bashrc":

cat >> ~/.bashrc << "EOF"
export MAKEFLAGS=-j$(nproc)
EOF

Substitua "$(nproc)" pelo número de núcleos lógicos que você deseja usar se não quiser usar todos os núcleos lógicos.

Finalmente, para garantir que o ambiente esteja totalmente preparado para a construção das ferramentas temporárias, force o shell bash a ler o perfil do(a) novo(a) usuário(a):

source ~/.bash_profile

Muitas pessoas gostariam de saber de antemão aproximadamente quanto tempo leva para compilar e instalar cada pacote. Devido ao Linux From Scratch poder ser construído em muitos sistemas, é impossível fornecer estimativas de tempo absolutas. O maior pacote (gcc) levará aproximadamente cinco (05) minutos nos sistemas mais rápidos, mas poderia levar dias nos sistemas mais lentos! Em vez de fornecer tempos atuais, a medida Unidade Padrão de Construção (UPC) será usada.

A medida UPC funciona como segue. O primeiro pacote a ser compilado é o binutils no Capítulo 5. O tempo necessário para compilar usando um núcleo é o que nós nos referiremos como a Unidade Padrão de Construção ou UPC. Todos os outros tempos de compilação serão expressos relativamente a esse tempo.

Por exemplo, considere um pacote cujo tempo de compilação é de quatro e meio (4,5) UPCs. Isso significa que, se o teu sistema precisou de quatro (04) minutos para compilar e instalar a primeira passagem do binutils, será necessário aproximadamente dezoito (18) minutos para construir o pacote de exemplo. Felizmente, a maioria dos tempos de construção é menor que uma UPC.

As UPCs não são totalmente precisas, pois dependem de muitos fatores, incluindo a versão do GCC do sistema anfitrião. Elas são fornecidas aqui para dar uma estimativa de quanto tempo pode levar para instalar um pacote, mas os números podem variar tanto quanto dúzias de minutos em alguns casos.

Em alguns sistemas mais novos, a placa-mãe é capaz de controlar a velocidade do clock do sistema. Isso pode ser controlado com um comando como powerprofilesctl. Isso não está disponível no LFS, mas pode estar disponível na distribuição anfitriã. Depois que o LFS estiver completo, ele pode ser adicionado a um sistema com os procedimentos na página power-profiles-daemon do BLFS. Antes de mensurar o tempo de construção de qualquer pacote, é aconselhável usar um perfil de eletricidade do sistema configurado para desempenho máximo (e consumo máximo de eletricidade). Caso contrário, o valor da UPC mensurado pode ser impreciso porque o sistema pode reagir diferentemente ao construir binutils-passagem1 ou outros pacotes. Esteja ciente de que uma imprecisão significativa ainda pode aparecer mesmo se o mesmo perfil for usado para ambos os pacotes, porque o sistema pode responder mais lentamente se estiver ocioso ao iniciar o procedimento de construção. Configurar o perfil de eletricidade para “performance” minimizará esse problema. E, obviamente, fazer isso também fará com que o sistema construa o LFS mais rápido.

Se powerprofilesctl estiver disponível, emita o comando powerprofilesctl set performance para selecionar o perfil performance. Algumas distribuições fornecem o comando tuned-adm para gerenciar os perfis em vez de powerprofilesctl; nessas distribuições emita o comando tuned-adm profile throughput-performance para selecionar o perfil throughput-performance.

A maioria dos pacotes fornece uma suíte de teste. Executar a suíte de teste para um pacote recém construído é uma boa ideia, pois pode fornecer uma “verificação de sanidade” indicando que tudo compilou corretamente. Uma suíte de teste que ultrapassa o conjunto de verificações dela geralmente prova que o pacote está funcionando como a(o) desenvolvedora(r) pretendia. Não garante, entretanto, que o pacote está totalmente livre de defeitos.

Algumas suítes de teste são mais importantes que outras. Por exemplo, as suítes de teste para o conjunto de ferramentas central—GCC, binutils e glibc—são de máxima importância devido ao papel central delas em um sistema que funcione adequadamente. As suítes de teste para GCC e glibc podem levar bastante tempo para completarem, especialmente em hardware mais lento, mas são fortemente recomendadas.

Um problema comum com a execução de suítes de teste para o binutils e o GCC é ficar sem os pseudo terminais (PTYs). Isso pode resultar em um alto número de testes com falhas. Isso pode acontecer por muitas razões, mas a causa mais provável é a de que o sistema anfitrião não tem o sistema de arquivos devpts configurado corretamente. Esse problema é discutido em maiores detalhes em https://www.linuxfromscratch.org/lfs/faq.html#no-ptys.

Algumas vezes suítes de testes de pacotes falharão por razões as quais as(os) desenvolvedoras(es) estão cientes e consideraram não-críticas. Consulte os registros localizados em https://www.linuxfromscratch.org/lfs/build-logs/12.2/ para verificar quando essas falhas são esperadas ou não. Esse sítio é válido para todas as suítes de teste ao longo deste livro.

Este capítulo mostra como construir um compilador cruzado e as ferramentas associadas dele. Apesar de aqui a compilação cruzada ser falseada, os princípios são os mesmos que aqueles para um conjunto de ferramentas cruzado real.

Os aplicativos compilados neste capítulo serão instalados sob o diretório $LFS/tools para mantê-los separados dos arquivos instalados nos capítulos seguintes. As bibliotecas, por outro lado, são instaladas no lugar final delas, dado que elas pertencem ao sistema que queremos construir.

Este capítulo mostra como compilar cruzadamente utilitários básicos usando o recém construído conjunto de ferramentas cruzados. Esses utilitários são instalados no local final deles, porém ainda não podem ser usados. Tarefas básicas ainda dependem das ferramentas do anfitrião. Apesar disso, as bibliotecas instaladas são usadas quando da vinculação.

Usar os utilitários será possível no próximo capítulo após entrada no ambiente “chroot”. Porém, todos os pacotes construídos no presente capítulo precisam ser construídos antes que façamos isso. Dessa forma nós ainda não podemos ficar independentes do sistema anfitrião.

Uma vez mais, permita-nos relembrar que a configuração inapropriada de LFS junto com a construção como root, possivelmente torne teu computador não usável. Este capítulo inteiro precisa ser feito como usuário(a) lfs, com o ambiente conforme descrito na Seção 4.4, “Configurando o Ambiente.”

Este capítulo mostra como construir os bits ausentes finais do sistema temporário: as ferramentas necessárias para construir os vários pacotes. Agora que todas as dependências circulares foram resolvidas, um ambiente “chroot”, completamente isolado do sistema operacional anfitrião (exceto pelo núcleo em execução), pode ser usado para a construção.

Para a operação adequada do ambiente isolado, alguma comunicação com o núcleo em execução precisa ser estabelecida. Isso é feito por meio dos assim chamados Sistemas de Arquivos Virtuais do Núcleo, que serão montados antes da entrada no ambiente chroot. Você possivelmente queira verificar se eles estão montados emitindo o comando findmnt.

Até a Seção 7.4, “Entrando no Ambiente Chroot”, os comandos precisam ser executados como root, com a variável LFS configurada. Após a entrada no chroot, todos os comandos são executados como root, por sorte sem acesso ao SO do computador no qual que você construiu o LFS. Seja cuidadoso(a) de qualquer maneira, dado que é fácil destruir o sistema LFS inteiro com comandos mau formados.

Atualmente, a hierarquia de diretório inteira em $LFS é de propriedade do(a) usuário(a) lfs, um(a) usuário(a) que existe somente no sistema anfitrião. Se os diretórios e os arquivos sob $LFS forem mantidos como estão, [então] eles serão de propriedade de um ID de usuária(o) sem uma conta correspondente. Isso é perigoso, pois uma conta de usuária(o) criada posteriormente poderia obter esse mesmo ID de usuária(o) e se tornaria proprietária(o) de todos os arquivos sob $LFS, dessa forma expondo esses arquivos a possível manipulação maliciosa.

Para endereçar esse problema, mude a propriedade dos diretórios $LFS/* para usuária(o) root executando o seguinte comando:

chown --from lfs -R root:root $LFS/{usr,lib,var,etc,bin,sbin,tools}
case $(uname -m) in
  x86_64) chown --from lfs -R root:root $LFS/lib64 ;;
esac

Os aplicativos executando no espaço do(a) usuário(a) utilizam vários sistemas de arquivos criados pelo núcleo para comunicar com o próprio núcleo. Esses sistemas de arquivos são virtuais: nenhum espaço em disco é usado por eles. O conteúdo desses sistemas de arquivos reside em memória. Esses sistemas de arquivos precisam estar montados na árvore de diretórios $LFS, de modo que os aplicativos consigam encontrá-los no ambiente chroot.

Comece criando os diretórios nos quais esses sistemas de arquivos virtuais serão montados:

mkdir -pv $LFS/{dev,proc,sys,run}

mount -v --bind /dev $LFS/dev

mount -vt devpts devpts -o gid=5,mode=0620 $LFS/dev/pts
mount -vt proc proc $LFS/proc
mount -vt sysfs sysfs $LFS/sys
mount -vt tmpfs tmpfs $LFS/run

if [ -h $LFS/dev/shm ]; then
  install -v -d -m 1777 $LFS$(realpath /dev/shm)
else
  mount -vt tmpfs -o nosuid,nodev tmpfs $LFS/dev/shm
fi

Agora que todos os pacotes que são exigidos para construir o resto das ferramentas necessárias estão no sistema, é tempo de entrar no ambiente chroot e finalizar a instalação das ferramentas temporárias. Esse ambiente também será usado para instalar o sistema final. Como usuária(o) root, execute o seguinte comando para entrar no ambiente que é, neste momento, povoado apenas com as ferramentas temporárias:

chroot "$LFS" /usr/bin/env -i   \
    HOME=/root                  \
    TERM="$TERM"                \
    PS1='(lfs chroot) \u:\w\$ ' \
    PATH=/usr/bin:/usr/sbin     \
    MAKEFLAGS="-j$(nproc)"      \
    TESTSUITEFLAGS="-j$(nproc)" \
    /bin/bash --login

Se você não quiser usar todos os núcleos lógicos disponíveis, [então] substitua "$(nproc)" pelo número de núcleos lógicos que você deseja usar para construir pacotes neste capítulo e nos capítulos seguintes. As suítes de teste de alguns pacotes (notadamente "Autoconf", "Libtool" e "Tar") no Capítulo 8 não são afetadas por "MAKEFLAGS"; em vez disso, elas usam uma variável de ambiente "TESTSUITEFLAGS". Nós configuramos isso aqui também para executar essas suítes de teste com vários núcleos.

A opção -i dada para o comando env limpará todas as variáveis no ambiente chroot. Depois disso, somente as variáveis HOME, TERM, PS1, e PATH são configuradas novamente. A construção TERM=$TERM configura a variável TERM dentro do chroot para o mesmo valor que fora do chroot. Essa variável é necessária, de modo que aplicativos como o vim e o less possam operar adequadamente. Se outras variáveis forem desejadas, tais como CFLAGS ou CXXFLAGS, [então] esse é um bom lugar para configurá-las.

Deste ponto em diante, não existe mais necessidade de usar a variável LFS, pois todo o trabalho estará restrito ao sistema de arquivos do LFS; o comando chroot executa o shell Bash com o diretório raiz (/) configurado para $LFS.

Observe que /tools/bin não está no PATH. Isso significa que o conjunto de ferramentas cruzadas não mais será usado.

Observe também que o "prompt" do "bash" dirá "I have no name!" Isso é normal porque o arquivo "/etc/passwd" ainda não foi criado.

É tempo de criar a estrutura completa de diretórios no sistema de arquivos do LFS.

Crie alguns diretórios de nível de raiz que não estão no conjunto limitado exigido nos capítulos anteriores emitindo o seguinte comando:

mkdir -pv /{boot,home,mnt,opt,srv}

Crie o conjunto exigido de subdiretórios abaixo do nível de raiz emitindo os seguintes comandos:

mkdir -pv /etc/{opt,sysconfig}
mkdir -pv /lib/firmware
mkdir -pv /media/{floppy,cdrom}
mkdir -pv /usr/{,local/}{include,src}
mkdir -pv /usr/lib/locale
mkdir -pv /usr/local/{bin,lib,sbin}
mkdir -pv /usr/{,local/}share/{color,dict,doc,info,locale,man}
mkdir -pv /usr/{,local/}share/{misc,terminfo,zoneinfo}
mkdir -pv /usr/{,local/}share/man/man{1..8}
mkdir -pv /var/{cache,local,log,mail,opt,spool}
mkdir -pv /var/lib/{color,misc,locate}

ln -sfv /run /var/run
ln -sfv /run/lock /var/lock

install -dv -m 0750 /root
install -dv -m 1777 /tmp /var/tmp

Diretórios são, por padrão, criados com modo de permissão 755, mas isso não é desejável em todos os lugares. Nos comandos acima, duas mudanças são feitas—uma para o diretório home do(a) usuário(a) root e outra para os diretórios para arquivos temporários.

A primeira mudança de modo assegura que nem toda pessoa possa entrar no diretório "/root"—o mesmo que um(a) usuário(a) normal faria com o próprio diretório "home" dele ou dela. A segunda mudança de modo garante que qualquer usuário(a) consiga escrever nos diretórios "/tmp" e "/var/tmp", mas não consiga remover deles os arquivos de outros(as) usuários(as). A última é proibida pelo assim chamado “sticky bit”, o bit mais alto (1) na máscara de bits 1777.

Historicamente, o Linux manteve uma lista dos sistemas de arquivos montados no arquivo /etc/mtab. Os Núcleos modernos mantém essa lista internamente e a expõem para o(a) usuário(a) via sistema de arquivos /proc. Para satisfazer utilitários que esperam encontrar o /etc/mtab, crie o seguinte link simbólico:

ln -sv /proc/self/mounts /etc/mtab

Crie um arquivo /etc/hosts básico para ser referenciado em algumas suítes de teste e em um dos arquivos de configuração do Perl também:

cat > /etc/hosts << EOF
127.0.0.1  localhost $(hostname)
::1        localhost
EOF

Para que o(a) usuário(a) root seja capaz de logar e para que o nome “root” seja reconhecido, precisam existir entradas relevantes nos arquivos /etc/passwd e /etc/group.

Crie o arquivo /etc/passwd executando o seguinte comando:

cat > /etc/passwd << "EOF"
root:x:0:0:root:/root:/bin/bash
bin:x:1:1:bin:/dev/null:/usr/bin/false
daemon:x:6:6:Daemon User:/dev/null:/usr/bin/false
messagebus:x:18:18:D-Bus Message Daemon User:/run/dbus:/usr/bin/false
uuidd:x:80:80:UUID Generation Daemon User:/dev/null:/usr/bin/false
nobody:x:65534:65534:Unprivileged User:/dev/null:/usr/bin/false
EOF

A senha atual para root será configurada posteriormente.

Crie o arquivo /etc/group executando o seguinte comando:

cat > /etc/group << "EOF"
root:x:0:
bin:x:1:daemon
sys:x:2:
kmem:x:3:
tape:x:4:
tty:x:5:
daemon:x:6:
floppy:x:7:
disk:x:8:
lp:x:9:
dialout:x:10:
audio:x:11:
video:x:12:
utmp:x:13:
cdrom:x:15:
adm:x:16:
messagebus:x:18:
input:x:24:
mail:x:34:
kvm:x:61:
uuidd:x:80:
wheel:x:97:
users:x:999:
nogroup:x:65534:
EOF

Os grupos criados não são parte de nenhum padrão—eles são grupos decididos em parte pelas exigências da configuração do Udev no Capítulo 9 e em parte pelas convenções comuns empregadas por um número de distribuições Linux existentes. Adicionalmente, algumas suítes de teste dependem de usuárias(os) ou grupos específicas(os). A Linux Standard Base (LSB, disponível em http://refspecs.linuxfoundation.org/lsb.shtml) somente recomenda que, além do grupo root com um ID de Grupo (GID) de 0, um grupo bin com um GID de 1 esteja presente. O GID de 5 é amplamente usado para o grupo tty e o número 5 também é usado no /etc/fstab para o sistema de arquivos devpts. Todos os outros nomes de grupo e GIDs podem ser escolhidos livremente pelo(a) administrador(a) do sistema, uma vez que aplicativos bem escritos não dependem de números de GID, mas sim usam o nome do grupo.

O ID 65534 é usado pelo núcleo para NFS e espaços de nome de usuário(a) separados para usuários(as) e grupos não mapeados(as) (aqueles(as) existem no servidor NFS ou no espaço de nome de usuário pai, porém “não existem” na máquina local ou no espaço de nome separado). Nós atribuímos nobody e nogroup para evitar um ID não nomeado. Porém, outras distribuições possivelmente tratem esse ID diferentemente, de forma que qualquer aplicativo portável não deveria depender dessa atribuição.

Alguns pacotes precisam de um código de idioma.

localedef -i C -f UTF-8 C.UTF-8

Alguns testes no Capítulo 8 precisam de um(a) usuário(a) regular. Nós adicionamos esse(a) usuário(a) aqui e deletamos essa conta ao final daquele capítulo.

echo "tester:x:101:101::/home/tester:/bin/bash" >> /etc/passwd
echo "tester:x:101:" >> /etc/group
install -o tester -d /home/tester

Para remover o prompt “I have no name!”, inicie um novo shell. Uma vez que os arquivos /etc/passwd e /etc/group tenham sido criados, a resolução de nome de usuária(o) e nome de grupo agora funcionará:

exec /usr/bin/bash --login

Os aplicativos login, agetty e init (e outros) usam um número de arquivos de registro para registrar informação, tais como quem esteve logada(o) no sistema e quando. Entretanto, esses aplicativos não escreverão nos arquivos de registro se eles já não existirem. Inicialize os arquivos de registro e dê a eles permissões adequadas:

touch /var/log/{btmp,lastlog,faillog,wtmp}
chgrp -v utmp /var/log/lastlog
chmod -v 664  /var/log/lastlog
chmod -v 600  /var/log/btmp

O arquivo /var/log/wtmp registra todos os logins e logouts. O arquivo /var/log/lastlog registra quando cada usuária(o) se logou pela última vez. O arquivo /var/log/faillog registra tentativas de login falhas. O arquivo /var/log/btmp registra tentativas de login inválidas.

Neste capítulo, nós começamos a construir o sistema LFS pra valer.

A instalação desse software é direta. Embora em muitos casos as instruções de instalação pudessem ser mais curtas e mais genéricas, nós optamos por fornecer as instruções completas para cada pacote para minimizar as possibilidades de erros. A chave para aprender o que faz um sistema Linux funcionar é a de saber para que cada pacote é usado e porque você (ou o sistema) possivelmente precise dele.

Nós não recomendamos usar otimizações personalizadas. Elas podem fazer com que um aplicativo execute ligeiramente mais rápido, mas elas também possivelmente causem dificuldades de compilação e problemas quando executar o aplicativo. Se um pacote se recusar a compilar com uma otimização personalizada, [então] tente compilá-lo sem otimização e veja se isso corrige o problema. Mesmo se o pacote compilar quando usar uma otimização personalizada, existe o risco de que ele possivelmente tenha sido compilado incorretamente devido às complexas interações entre o código e as ferramentas de construção. Observe também que as opções -march e -mtune usando valores não especificados no livro não foram testadas. Isso possivelmente cause problemas com os pacotes do conjunto de ferramentas (Binutils, GCC e Glibc). Os pequenos ganhos potenciais alcançados personalizando-se otimizações de compilador frequentemente são superados pelos riscos. Construtoras(es) de primeira vez do LFS são encorajadas(os) a construir sem otimizações personalizadas.

Por outro lado, nós mantemos as otimizações habilitadas pela configuração padrão dos pacotes. Adicionalmente, as vezes, nós explicitamente habilitamos uma configuração otimizada fornecida por um pacote, porém não habilitada por padrão. Os(As) mantenedores(as) do pacote já testaram essas configurações e as consideraram seguras, de modo que não é provável que elas quebrariam a construção. Geralmente, a configuração padrão já habilita O2 ou O3, de forma que o sistema resultante ainda executará muito rápido sem qualquer otimização personalizada e será estável ao mesmo tempo.

Antes das instruções de instalação, cada página de instalação fornece informação a respeito do pacote, incluindo uma descrição concisa do que ele contém, aproximadamente quando tempo levará para construir, e quanto espaço de disco é exigido durante esse processo de construção. Seguindo as instruções de instalação, existe uma lista de aplicativos e de bibliotecas (juntamente com breves descrições) que o pacote instala.

Gerenciamento de Pacote é uma adição frequentemente solicitada ao Livro LFS. Um Gerenciador de Pacote rastreia a instalação de arquivos, tornando mais fácil remover e atualizar pacotes. Um bom gerenciador de pacote também lidará com os arquivos de configuração, especialmente para manter a configuração do(a) usuário(a) quando o pacote for reinstalado ou atualizado. Antes que você comece a questionar, NÃO—esta seção não falará nem recomendará qualquer gerenciador de pacote em particular. O que ela fornece é um resumo acerca das técnicas mais populares e como elas funcionam. O gerenciador de pacote perfeito para você possivelmente esteja entre essas técnicas ou possivelmente seja uma combinação de duas ou mais dessas técnicas. Esta seção menciona brevemente problemas que possivelmente surjam quando da atualização de pacotes.

Algumas razões porque nenhum gerenciador de pacote é mencionado no LFS ou no BLFS incluem:

Existem algumas dicas escritas no tópico do gerenciamento de pacote. Visite o Hints Project e veja se uma delas se adéqua às suas necessidades.

./configure --prefix=/usr/pkg/libfoo/1.1
make
make install

./configure --prefix=/usr
make
make DESTDIR=/usr/pkg/libfoo/1.1 install