Por que o LFS e o CLFS alteram o caminho usado para encontrar o vinculador dinâmico?

Question

Ambos LFS e CLFS aplica correções à fonte do GCC antes da criação.

Os patches do CLFS estão um pouco mais envolvidos do que os patches do LFS, mas o que eles têm em comum é a mudança do caminho usado para encontrar o vinculador dinâmico. Neste caso, ele foi movido para o local onde uma nova versão do glibc será construída.

Como, pelo menos no caso do CLFS, você está construindo uma cadeia de ferramentas cruzada e presumivelmente não é possível executar nada construído com essa cadeia em sua máquina de desenvolvimento, que diferença faz onde os programas do GCC procuram o vinculador dinâmico. Não é uma operação de tempo de execução que nunca acontecerá de qualquer maneira? Além disso, se você construiu um binário com este GCC, um que requeria bibliotecas compartilhadas, e tentou executá-lo em seu destino, o caminho para o linker dyanmic agora estaria errado?

Além disso, o (C) LFS modifica o STANDARD_STARTFILE_PREFIX_X para apontar para $INSTALL_PATH/tools/lib/ . Esses caminhos não seriam presumivelmente verificados quando / se você especificar --with-sysroot ? Depois de criar o GCC com --with-sysroot , se eu verificar --preint-search-dirs , não o vejo procurando em nenhum caminho além daqueles referenciados para o prefixo ou --with-sysroot .

    

Answer 1

As páginas que você vinculou são para construir uma cadeia de ferramentas temporária que é então usada para construir o sistema final no Capítulo 6 do LFS. O GCC no Capítulo 6 é compilado sem nenhum patch. Os patches na cadeia de ferramentas temporária estão disponíveis apenas para permitir a compilação adicional de pacotes, independentemente das ferramentas que o sistema host está usando.

    

Answer 2

(C) O LFS se esforça muito para construir um sistema linux com o menor número possível de conexões com a máquina de construção. Como resultado, algumas das etapas podem parecer desnecessárias, redundantes ou planejadas. Aqui está (um subconjunto do) processo CLFS que aborda a questão principal:

1. Ch5: Cross binutils
2. Ch5: 1ª passagem cruzada no GCC
3. Ch5: Glibc (que pode ser usado por um compilador cruzado e nativo de destino), é instalado com o prefixo /tools
4. Ch5: segunda passagem cruzada gcc. O dynamic-linker-path-patch é aplicado aqui para apontar para /tools , que é um link simbólico para $CLFS/tools , em que $ CLFS é a raiz do sistema de arquivos do destino.
5. Ch6: Use a segunda passagem cruzada do gcc para criar um monte de novas ferramentas que serão nativas para o alvo, incluindo uma versão do gcc para ser executada nativa no alvo. Conspicuamente ausente desta lista é outra cópia da glibc. Isso não é necessário porque o que foi criado anteriormente está bom por enquanto.
6. Ch10: Inicialize / chroot no sistema de destino, que agora tem /tools no mesmo local que sua máquina de construção. Isso permite que ferramentas construídas (como nativas) anteriormente acessem o vinculador dinâmico. Agora você vai fazer glibc novamente, mas desta vez ele vai para o padrão /usr (em vez de /tools/usr )

A raiz da pergunta tinha a ver com o caminho do vinculador dinâmico e com o fato de que ele aparece em relação à máquina de compilação. A resposta é basicamente que o OP (eu) não estava pensando em como havia um link simbólico entre / tools e ${CLFS}/tools e que o patch foi aplicado para fazer / tools o caminho da raiz para o linker.

Não tenho resposta para a questão STANDARD_STARTFILE_PREFIX_X .