Não é possível codificar caminho de pesquisa da biblioteca de binutils

Question

Eu tento criar o linux do zero sem acesso root, a um localização personalizada e dentro de uma instalação existente do CentOS.

Defino LFS como um caminho absoluto no meu diretório inicial, LFS_TGT=x86_64-lfs-linux-gnu e export PATH=${LFS}/tools/bin:$PATH

Construído binutils-2.28 com:

../configure --prefix=${LFS}/tools      \
             --with-sysroot=$LFS        \
             --with-lib-path=${LFS}/tools/lib \
             --target=$LFS_TGT          \
             --disable-nls              \
             --disable-werror

Depois disso, vinculei ${LFS}/tools/lib64 a ${LFS}/tools/lib , instalei o cabeçalho do kernel em linux-2-6-32-8 , gcc-4.9.2 e criei glibc-2.11.1 , tudo no diretório ${LFS}/tools .

Então eu digitei x86_64-lfs-linux-gnu-ld -lc e recebi o seguinte erro:

x86_64-lfs-linux-gnu-ld: cannot find -lc

Eu cd ${LFS}/tools/lib64 e, em seguida, x86_64-lfs-linux-gnu-ld libc.so apresentam o seguinte erro:

x86_64-lfs-linux-gnu-ld: cannot find ${LFS}/tools/lib/libc.so.6 inside ${LFS}

Eu não consigo entender esse erro. O arquivo libc.so.6 está no local correto.

Eu pensei que a opção --with-lib-path=${LFS}/tools/lib para configuração de binutils-2.28 diria a x86_64-lfs-linux-gnu-ld para procurar bibliotecas em ${LFS}/tools/lib sem precisar definir a variável LD_LIBRARY_PATH environmental. Mas este não é o caso.

Por quê?

A definição de LD_LIBRARY_PATH para ${LFS}/tools/lib faria com que tudo falhassesse na segmentação, incluindo coisas que acabei de criar e os principais utilitários do CentOS.

Atualização:

Eu também tentei:

../configure --prefix=${LFS}/tools      \
             --with-sysroot=$LFS        \
             --with-lib-path=tools/lib  \  # this is changed
             --target=$LFS_TGT          \
             --disable-nls              \
             --disable-werror

Mas esses dois erros ainda acontecem.

    

Answer 1

Eu tive o mesmo problema e depois de 2 dias de luta, encontrei o problema. o problema é com a glibc. ld encontra o arquivo libc.so e tenta vinculá-lo, mas esse arquivo é um script de vinculador que informa ao vinculador quais arquivos vincular. o conteúdo é:

/* GNU ld script
Use the shared library, but some functions are only in
the static library, so try that secondarily.  */
OUTPUT_FORMAT(elf64-x86-64)
GROUP ( ${LFS}/tools/lib/libc.so.6 ${LFS}/tools/lib/libc_nonshared.a  AS_NEEDED ( ${LFS}/tools/lib/ld-linux-x86-64.so.2 ) )

como gcc passa a opção --sysroot=${LFS} para ld. ld adiciona ${LFS} a ${LFS}/tools/lib/libc.so.6 e tenta vinculá-lo, o que resulta no erro acima.

glibc_source_dir/Makerules line 1082 :

install: $(inst_libdir)/libc.so
$(inst_libdir)/libc.so: $(common-objpfx)format.lds \
        $(common-objpfx)libc.so$(libc.so-version) \
        $(inst_libdir)/$(patsubst %,$(libtype.oS),\
                      $(libprefix)$(libc-name)) \
        $(+force)
        (echo '/* GNU ld script';\
 echo '   Use the shared library, but some functions are only in';\
 echo '   the static library, so try that secondarily.  */';\
 cat $<; \
 echo 'GROUP ( $(slibdir)/libc.so$(libc.so-version)' \
      '$(libdir)/$(patsubst %,$(libtype.oS),$(libprefix)$(libc-name))'\
      ' AS_NEEDED (' $(rtlddir)/$(rtld-installed-name) ') )' \
) > [email protected]
mv -f [email protected] $@

O destino de instalação da glibc instala todas as bibliotecas em $(inst_libdir) , que é $(DESTDIR)$(prefix) , mas usa $(libdir) e $(slibdir) ao gravar o arquivo libc.so , que são reletivas para $(prefix) não $(DESTDIR) .

solução: você tem que configurar o glibc com --prefix=/tools e depois instalá-lo com: DESTDIR=${LFS} make install

    

Answer 2

Eu tive que construir uma nova versão do compilador (gcc-4.4.3 para compilar a arquitetura do host, em vez da compilação cruzada) porque o compilador do centos era 4.1.2 e isso é muito antigo para construir o glibc-2.11. 1 Depois disso, eu uso este novo compilador para construir a cadeia de ferramentas de compilação cruzada em "Linux from scratch versão 6.6". Essa versão não me pediu para fazer nenhum sed até agora ... Eu acho que vou configurar o compilador cross e então usá-lo para construir versões mais novas do gcc e glibc.