5.7. Ajustar las herramientas

Ahora que se han instalado las librerías de C temporales, todas las herramientas que compilemos en el resto de este capítulo deberían enlazarse contra ellas. Para conseguirlo, deben ajustarse el enlazador y el fichero specs del compilador.

El enlazador, que se ajustó al final del primer paso de Binutils, debe renombrarse para que pueda ser encontrado y utilizado correctamente. Primero, haz una copia de seguridad del enlazador original, despues reemplazalo con el enlazador ajustado. También haremos un enlace a su contraparte en /tools/$(gcc -dumpmachine)/bin:

mv -v /tools/bin/{ld,ld-old}
mv -v /tools/$(gcc -dumpmachine)/bin/{ld,ld-old}
mv -v /tools/bin/{ld-new,ld}
ln -sv /tools/bin/ld /tools/$(gcc -dumpmachine)/bin/ld

Desde ahora todo se enlazará solamente contra las librerías que hay en /tools/lib.

Lo siguiente esapuntar GCC al nuevo enlazador dinámico. Esto se hace volcando el fichero “specs”de GCC a un lugar en el que GCC lo busque por defecto. Una simple sustitución sed cambia el enlazador dinámico que será usado por GCC.

Recomendamos que copies y pegues el siguiente comando para asegurar que no hay errores. Asegúrate de revisar visualmente el fichero specs para verificar que cada aparición de “/lib/ld-linux.so.2” ha sido reemplazada por “/tools/lib/ld-linux.so.2”:

[Importante]

Importante

Si estás trabajando sobre una plataforma en la que el nombre del enlazador dinámico no es ld-linux.so.2, en el siguiente comando debes sustituir ld-linux.so.2 con el nombre del enlazador dinámico de tu plataforma. En caso necesario consulta la Sección 5.2, “Notas técnicas sobre las herramientas”.

gcc -dumpspecs | sed 's@/lib/ld-linux.so.2@/tools&@g' \
  > `dirname $(gcc -print-libgcc-file-name)`/specs

Durante el proceso de construcción, GCC ejecuta un guión (fixincludes) que explora el sistema buscando ficheros de cabecera que puedan necesitar ser corregidos (que pueden contener errores de sintaxis, por ejemplo), e instala las versiones corregidas en un directorio privado. Existe la posibilidad de que, como resultado de este proceso, algunos ficheros de cabecera del sistema anfitrión se hayan colado dentro de dicho directorio privado de cabeceras de GCC. Como el resto de este capítulo sólo necesita las cabeceras de GCC y Glibc, que ya han sido instaladas, cualquier cabecera “fijada” puede borrarse sin problemas. Esto ayuda a evitar que cualquier cabecera del anfitrión contamine el entorno de construcción. Ejecuta los siguientes comandos para eliminr dichos ficheros de cabecera (puede que encuentres más facil copiar y pegar estos comandos en vez de teclearlos, debido a su longitud):

GCC_INCLUDEDIR=`dirname $(gcc -print-libgcc-file-name)`/include &&
find ${GCC_INCLUDEDIR}/* -maxdepth 0 -xtype d -exec rm -rvf '{}' \; &&
rm -vf `grep -l "DO NOT EDIT THIS FILE" ${GCC_INCLUDEDIR}/*` &&
unset GCC_INCLUDEDIR
[Atención]

Atención

En este punto es obligatorio parar y asegurarse de que las operaciones básicas (compilación y enlazado) de las nuevas herramientas funcionan como se espera. Para esto vamos a hacer una simple comprobación:

echo 'main(){}' > dummy.c
cc dummy.c
readelf -l a.out | grep ': /tools'

Si todo funciona correctamente, no debe haber errores y la salida del último comando debe ser:

[Requesting program interpreter:
    /tools/lib/ld-linux.so.2]

[Intérprete de programa solicitado:
    /tools/lib/ld-linux.so.2]

Confirma que /tools/lib aparezca como el prefijo de tu enlazador dinámico.

Si no recibes una salida como la mostrada arriba, o no hay salida alguna, algo está seriamente mal. Investiga y revisa tus pasos para encontrar el problema y corregirlo. El problema debe resolverse antes de continuar. Primero, repite la comprobación de sanidad usando gcc en vez de cc. Si esto funciona significa que falta el enlace simbólico /tools/bin/cc. Vuelve a la Sección 5.4, “GCC-4.2.1 - Fase 1” e instala el enlace simbólico. Seguidamente, asegúrate de que tu PATH es correcto. Puedes comprobarlo ejecutando echo $PATH y verificando que /tools/bin está en cabeza de la lista. Si el PATH está mal puede significar que no has ingresado como usuario lfs o que algo salió mal en la Sección 4.4, “Configuración del entorno”. Otra opción es que algo pudo ir mal en el anterior arreglo del fichero specs. En este caso, repite el arreglo del fichero asegurándote de copiar y pegar los comandos como se recomendó.

Cuando todo esté bien, borra los ficheros de prueba:

rm -v dummy.c a.out
[Nota]

Nota

La construcción de TCL en la siguiente sección servirá como comprobación adicional de que las herramientas se han construido correctamente. Si la construcción de TCL falla, esto es una indicación de que algo fué mal durante la instalación de Binutils, GCC o Glibc, pero no con el propio TCL.