5.5. Glibc-2.42

5.5.1. Instalação da Glibc

Primeiro, crie um link simbólico para conformidade com a LSB. Adicionalmente, para x86_64, crie um link simbólico de compatibilidade exigido para a operação adequada do carregador dinâmico de biblioteca:

case $(uname -m) in
    i?86)   ln -sfv ld-linux.so.2 $LFS/lib/ld-lsb.so.3
    ;;
    x86_64) ln -sfv ../lib/ld-linux-x86-64.so.2 $LFS/lib64
            ln -sfv ../lib/ld-linux-x86-64.so.2 $LFS/lib64/ld-lsb-x86-64.so.3
    ;;
esac

Alguns dos aplicativos Glibc usam o diretório não conforme com a FHS /var/db para armazenar os dados em tempo de execução deles. Aplique o seguinte remendo para fazer com que tais aplicativos armazenem os dados em tempo de execução deles nos locais conformes com a FHS:

patch -Np1 -i ../glibc-2.42-fhs-1.patch

A documentação da Glibc recomenda construir a Glibc em um diretório dedicado à construção:

mkdir -v build
cd      build

Assegure que os utilitários ldconfig e sln sejam instalados em /usr/sbin:

echo "rootsbindir=/usr/sbin" > configparms

A seguir, prepare a Glibc para compilação:

../configure                             \
      --prefix=/usr                      \
      --host=$LFS_TGT                    \
      --build=$(../scripts/config.guess) \
      --disable-nscd                     \
      libc_cv_slibdir=/usr/lib           \
      --enable-kernel=5.4

Durante este estágio o seguinte aviso pode aparecer:

O ausente ou incompatível aplicativo msgfmt geralmente é inofensivo. Esse aplicativo msgfmt é parte do pacote Gettext, que a distribuição anfitriã deveria fornecer.

Compile o pacote:

make

Instale o pacote:

make DESTDIR=$LFS install

Corrija caminho codificado rigidamente para o carregador de executável no script ldd:

sed '/RTLDLIST=/s@/usr@@g' -i $LFS/usr/bin/ldd

Agora que nosso conjunto cruzado de ferramentas está no lugar, é importante garantir que compilação e vinculação funcionarão conforme esperado. Nós fazemos isso realizando algumas verificações de sanidade:

echo 'int main(){}' | $LFS_TGT-gcc -x c - -v -Wl,--verbose &> dummy.log
readelf -l a.out | grep ': /lib'

Não deveriam existir erros, e a saída gerada do último comando será (levando em consideração diferenças específicas da plataforma no nome do vinculador dinâmico):

[Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]

Observe que esse caminho não deveria conter /mnt/lfs (ou o valor da variável LFS se você usou uma diferente). O caminho é resolvido quando o programa compilado for executado, e isso só deveria acontecer depois que nós entrarmos no ambiente chroot onde o núcleo consideraria $LFS como o diretório raiz (/).

Agora certifique-se de que nós estamos configurados para usar os arquivos corretos de iniciação:

grep -E -o "$LFS/lib.*/S?crt[1in].*succeeded" dummy.log

A saída gerada do último comando deveria ser:

/mnt/lfs/lib/../lib/Scrt1.o succeeded
/mnt/lfs/lib/../lib/crti.o succeeded
/mnt/lfs/lib/../lib/crtn.o succeeded

Verifique se o compilador está procurando os arquivos corretos de cabeçalho:

grep -B3 "^ $LFS/usr/include" dummy.log

Esse comando deveria retornar a seguinte saída gerada:

#include <...> search starts here:
 /mnt/lfs/tools/lib/gcc/x86_64-lfs-linux-gnu/15.2.0/include
 /mnt/lfs/tools/lib/gcc/x86_64-lfs-linux-gnu/15.2.0/include-fixed
 /mnt/lfs/usr/include

Novamente, o diretório nomeado depois do teu tripleto alvo possivelmente seja diferente do acima, dependendo da arquitetura do teu sistema.

Agora, verifique se o novo vinculador está sendo usado com os caminhos corretos de procura:

grep 'SEARCH.*/usr/lib' dummy.log |sed 's|; |\n|g'

Referências para caminhos que tenham componentes com '-linux-gnu' deveriam ser ignoradas, porém, do contrário, a saída gerada do último comando deveria ser:

SEARCH_DIR("=/mnt/lfs/tools/x86_64-lfs-linux-gnu/lib64")
SEARCH_DIR("=/usr/local/lib64")
SEARCH_DIR("=/lib64")
SEARCH_DIR("=/usr/lib64")
SEARCH_DIR("=/mnt/lfs/tools/x86_64-lfs-linux-gnu/lib")
SEARCH_DIR("=/usr/local/lib")
SEARCH_DIR("=/lib")
SEARCH_DIR("=/usr/lib");

Um sistema de 32 bits possivelmente use alguns outros diretórios, mas de qualquer maneira o aspecto importante aqui é que todos os caminhos deveriam começar com um sinal de igual (=), que seria substituído pelo diretório sysroot que nós configuramos para o vinculador.

Em seguida, tenha certeza de que nós estamos usando a libc correta:

grep "/lib.*/libc.so.6 " dummy.log

A saída gerada do último comando deveria ser:

attempt to open /mnt/lfs/usr/lib/libc.so.6 succeeded

Tenha certeza de que GCC está usando o vinculador dinâmico correto:

grep found dummy.log

A saída gerada do último comando deveria ser (levando em consideração diferenças específicas da plataforma no nome do vinculador dinâmico):

found ld-linux-x86-64.so.2 at /mnt/lfs/usr/lib/ld-linux-x86-64.so.2

Se a saída gerada não aparecer conforme mostrado acima ou não for recebida, então alguma coisa está seriamente errada. Investigue e refaça as etapas para descobrir onde está o problema e corrija-o. Quaisquer problemas deveriam ser resolvidos antes de se continuar com o processo.

Uma vez que tudo esteja funcionando corretamente, remova os arquivos de teste:

rm -v a.out dummy.log