El hilo del laberinto (Publicaciones sobre ccache)

Compilar una versión más moderna de "Bind" que la disponible en PkgSrc para SmartOS

Jesús Cea Avión — Fri, 17 Mar 2023 22:52:00 GMT

En Compilar "Bind" en PkgSrc para SmartOS con la opción de "dnstap" describo cómo compilar Bind en SmartOS con soporte dnstap, utilizando PkgSrc. Por favor, lee dicho artículo para entender qué estoy haciendo y por qué.

El principal problema en ese artículo es que estoy utilizando la versión trunk de PkgSrc para beneficiarme de una versión más moderna de Bind, pero eso implica que la versión compilada utiliza bibliotecas no disponibles en la paquetería estándar de SmartOS y tenemos que compilarlas, distribuirlas e instalarlas a mano.

Si en vez de utilizar la versión trunk de PkgSrc utilizamos la versión que se corresponda a la Zona SmartOS en la que vamos a instalar Bind, no necesitaremos hacer nada especial con las dependencias.

Nota

Para lo que sigue nos conviente conocer la filosofía de PkgSrc: En PkgSrc, de forma automática, se descarga una versión concreta del código fuente que queremos compilar, se verifica su hash para asegurarnos de que es la versión correcta y no nos están colando gato por liebre, se le aplican una serie de parches locales, que es lo que se mantiene en realidad en PkgSrc, se compila y se genera un paquete. Esta gestión separada del código fuente original y los parches locales que necesitamos en nuestro sistema es la piedra angular de PkgSrc. Permite, por ejemplo, que no se requiera colaboración por parte de los autores originales de los programas para que soporten nuestro sistema operativo. Esto va como anillo al dedo con SmartOS, porque no podemos contar con que nadie ajeno le de mimos y cuide de él.

Los cambios respecto a Compilar "Bind" en PkgSrc para SmartOS con la opción de "dnstap", serán:

Usamos una zona nativa SmartOS con la versión del software PkgSrc que se corresponda a las zonas nativas SmartOS donde vamos a instalar el Bind que compilamos, en vez de la versión trunk de PkgSrc:

[root@xXx ~]# imgadm avail|grep -i pkgbuild-lts
188ee9ce-540a-11eb-9cc1-2748cd10e5e2  pkgbuild-lts                    20.4.0        smartos  zone-dataset  2021-01-11
bd5afd7a-7ec1-11ec-80ab-7b01241031f6  pkgbuild-lts                    21.4.0        smartos  zone-dataset  2022-01-26
758a4572-911d-11ed-b841-00151714048c  pkgbuild-lts                    22.4.0        smartos  zone-dataset  2023-01-10

Queremos compilar Bind para utilizarlo en una zona 22.4.0, así que importamos esa versión de zona PkgSrc y la desplegamos en una zona de nuestra máquina SmartOS.

Entramos en la zona PkgSrc por SSH y le pedimos que cree un entorno virtual de compilación:

[root@PkgSrc ~]# run-sandbox 2022Q4-x86_64

It looks like this is the first sandbox creation for this pkgbuild.  It
will take longer than normal, as support packages need to be downloaded
first.  Subsequent runs will be much faster after they have been cached.

[...]

Unpacking bootstrap-2022Q4-x86_64 into /data/chroot/dev-2022Q4-x86_64...done.
Setting up environment...done.
Installing additional tools packages...done.
Logging in.  WARNING: On logout the sandbox will be destroyed.

,---.                   |     ,---. ,---.
`---. ,-.-. ,---. ,---. |---  |   | `---.  pkgbuild-lts
    | | | | ,---| |     |     |   |     |  22.4.0
`---' ` ' ' `---' `     `---' `---' `---'

--<root@PkgSrc>-(/data/chroot/dev-2022Q4-x86_64)-<~>--
->

Obsérvese que le estamos pidiendo un entorno de compilación 2022Q4-x86_64. En teoría las zonas PkgSrc modernas pueden compilar código para versiones más antiguas de las zonas SmartOS, solicitando la creación del entorno de compilación adecuado.

Leer más… (quedan 4 minutos de lectura)

Cómo usar "ccache" para compilar en PkgSrc de SmartOS (II)

Jesús Cea Avión — Mon, 23 Jan 2023 22:34:00 GMT

En Cómo usar "ccache" para compilar en PkgSrc de SmartOS explico cómo utilizar ccache a la hora de compilar paquetes PkgSrc.

Ahí propongo realizar un cambio en el fichero /data/pkgbuild/scripts/run-sandbox [1] para añadir lo siguiente al fichero .bashrc del entorno chroot:

# Ver el comentario en
# https://wiki.netbsd.org/tutorials/pkgsrc/build_ccache_distcc/
export CCACHE_DIR=/root/.ccache/
export PKGSRC_COMPILER=ccache gcc

La segunda línea no funciona correctamente en SmartOS porque ahí el fichero /opt/local/etc/mk.conf dentro del entorno chroot ignora la variable de entorno PKGSRC_COMPILER y fuerza un valor explícito de PKGSRC_COMPILER=gcc a la hora de compilar.

Por tanto, lo mejor es cambiar el fichero /data/pkgbuild/scripts/run-sandbox [1] para que modifique ese fichero a la hora de crear el entorno chroot. Sería cuestión de añadirle una línea como esta poco antes del final del fichero:

sed -i "s/^PKGSRC_COMPILER=/PKGSRC_COMPILER?=/g" ${chrootdir}${PKGBUILD_SYSCONFDIR}/mk.conf

Ese cambio en el fichero /opt/local/etc/mk.conf dentro del entorno chroot mantiene la definición por defecto de PKGSRC_COMPILER cuando no le hemos puesto un valor concreto por variable de entorno, pero la variable de entorno manda si existe. Así debería venir de serie en SmartOS. Usando expansiones shell, modificamos el fichero correcto sea cual sea el branch PkgSrc que estamos utilizando para generar el entorno chroot.

Además, el export estaba mal. Hay que poner el valor entre comillas. Por ejemplo:

export PKGSRC_COMPILER="ccache gcc"

[1]	(1, 2) Para estos cambios utilizo Ansible. No los hago a mano, que sería un coñazo cada vez que reprovisiono la zona SmartOS.

"ccache" persistente en el PkgSrc de SmartOS

Jesús Cea Avión — Wed, 24 Aug 2022 15:37:00 GMT

En Cómo usar "ccache" para compilar en PkgSrc de SmartOS describo cómo configurar el entorno PkgSrc de SmartOS para que utilice ccache y así beneficiarnos de una mayor velocidad de recompilación.

El problema que tenemos es que la caché de ccache se guarda dentro del entorno chroot y esto tiene dos efectos:

No podemos beneficiarnos del uso de ccache entre dos branches PkgSrc diferentes, algo que uso con frecuencia en SmartOS.
Cuando cerramos en entorno chroot, este se destruye. Esto elimina también la caché de ccache.

Cuando estoy trabajando en un proyecto largo, es común que lance el entorno chroot de forma pesistente dentro de una sesión screen, por lo que puede sobrevivir a lo largo de varias jornadas de trabajo, pero al terminar la tarea la cerraré y perderé la caché del ccache.

Lo ideal sería que la caché ccache se almacenase fuera del entorno chroot. Eso se puede hacer con facilidad de esta manera [1]:

Creamos un directorio /root/.chroot/ en la zona SmartOS.
Editamos los ficheros /data/pkgbuild/scripts/mksandbox y /data/pkgbuild/scripts/rmsandbox, buscamos la línea que pone for mount in ${LOFS_RW_MOUNTS}; do y la cambiamos por lo siguiente: for mount in ${LOFS_RW_MOUNTS} "/root/.ccache=/root/.ccache"; do.

Lo que estamos haciendo es añadir un loopback hacia /root/.ccache a la hora de crear el entorno chroot y desmontarlo a la hora de destruirlo.

De esta manera, los usos de ccache dentro de los diferentes entornos chroot utilizarán todos la misma caché y esta es persistente e independiente de la existencia de dichos entornos chroot.

[1]	Para estos cambios utilizo Ansible. No los hago a mano, que sería un coñazo cada vez que reprovisiono la zona SmartOS.

Cómo usar "ccache" para compilar en PkgSrc de SmartOS

Jesús Cea Avión — Thu, 21 Jul 2022 13:54:00 GMT

Utilizo muy frecuentemente el entorno de compilación PkgSrc para SmartOS y voy personalizándolo poco a poco para mejorar mi experiencia y ajustarlo mejor a mi forma de trabajar.

Estudiando la documentación de PkgSrc, me encuentro un capítulo interesante: Speeding up pkgsrc builds with ccache and distcc. Yo utilizo ccache en muchos de mis entornos y poder utilizarlo también en PkgSrc me resulta atractivo.

Los pasos descritos en esa web son generales para PkgSrc, pero, en el caso concreto de SmartOS, sus actualizaciones trimestrales, su entorno chroot, etc, encuentro más fácil meter esos cambios como variables de entorno que modificar ficheros de configuración (tendría que cambiar un fichero en cada uno de los branches que utilizo). Una forma simple de hacerlo en SmartOS es modificar el fichero /data/pkgbuild/scripts/run-sandbox [1] y añadirle lo siguiente en la creación del fichero .bashrc para el entorno chroot:

# Ver el comentario en
# https://wiki.netbsd.org/tutorials/pkgsrc/build_ccache_distcc/
export CCACHE_DIR=/root/.ccache/
export PKGSRC_COMPILER=ccache gcc

Obsérvese el detalle de definir CCACHE_DIR de forma explícita. La razón se explica en el comentario de Speeding up pkgsrc builds with ccache and distcc que, resumiendo, indica que si no se hace así, cada compilación utiliza una caché separada y, por tanto, no se reutiliza y no sirve de nada.

Con estos cambios, cuando intentemos compilar algo, se instalará ccache y se utilizará automáticamente.

Advertencia

Por algún motivo, la primera vez que compilamos algo con esta configuración nos va a salir el siguiente error:

checking for x86_64-sun-solaris2.11-gcc... gcc
checking whether the C compiler works... no
configure: error: C compiler cannot create executables
See `config.log' for more details
*** Error code 77

Haciendo bmake clean y volviéndolo a intentar, ya funciona bien.

Esto es algo a estudiar en el futuro.

¿Cuánto ganamos utilizando ccache? El efecto se nota más cuanto más larga es la compilación:

	normal	ccache
Apache	1:29	0:49
tor	3:25	1:02
python39	6:02	1:36

[1]	Para estos cambios utilizo Ansible. No los hago a mano, que sería un coñazo cada vez que reprovisiono la zona SmartOS.

Actualización 20220824: Tal vez te interese leer "ccache" persistente en el PkgSrc de SmartOS.

Actualización 20230123: Más sobre este tema en Cómo usar "ccache" para compilar en PkgSrc de SmartOS (II).

Ccache o cómo recompilar rápido y sin dolor

Jesús Cea Avión — Sat, 11 Aug 2018 18:18:00 GMT

En Recompila tu propio Kodi explico de pasada que el proyecto Kodi utiliza ccache [1] si está disponible en el sistema.

[1]	Ccache significa "Compiler Cache".

Ccache intercepta las llamadas al compilador de C y C++. Ccache comprueba sus ficheros de entrada expandidos (con las sustituciones de macros, variables de entorno, includes y demás ya sustituidos) y comprueba si ya tiene en su caché el fichero resultante de aplicar ese comando a esos ficheros de entrada. Si no es así, ejecuta el comando y se guarda una copia del resultado en su caché. Si ya teníamos el resultado en caché, nos ahorramos ejecutar el comando y ccache proporciona el resultado directamente.

Dado que compilar un fichero es un proceso costoso, poder ahorrárselo si no hay cambios respecto a una compilación anterior resulta muy conveniente.

Por ejemplo, compilar Kodi entero, pero teniendo una compilación previa relativamente cercana, necesita 36 minutos en mi portátil (viejo y cargado de actividad, eso sí). Compilarlo desde cero sin ccache necesita casi toda una jornada laboral.

Las estadísticas de ccache tras este proceso son interesantes:

Leer más… (quedan 6 minutos de lectura)

Recompila tu propio Kodi

Jesús Cea Avión — Mon, 16 Jul 2018 17:58:00 GMT

Toco bastante el código, así que la distribución precompilada de Kodi no me sirve. Para compilar Kodi por mi cuenta, hago lo siguiente:

$ cd  ~/hg/kodi/
$ git fetch
$ git checkout RAMA_QUE_NOS_INTERESA
$ mkdir /tmp/kodi; cd /tmp/kodi
$ cmake ~/hg/kodi/ -DCMAKE_INSTALL_PREFIX=/home/jcea/.kodi/
$ cmake --build . -- VERBOSE=1 -j$(getconf _NPROCESSORS_ONLN)
$ make install

Estas instrucciones descargan el código de Kodi, lo compilan y lo instalan.

Obsérvese el uso de getconf _NPROCESSORS_ONLN para obtener el número de procesadores en el ordenador y, de esta forma, aprovecharlos todos.

Un detalle muy interesante es que Kodi utilizará ccache, si lo tenemos instalado. Esto permite reducir el tiempo de compilación enormemente. Escribiré sobre esto en un artículo futuro.

Actualización 20180811: He escrito un artículo sobre ccache: Ccache o cómo recompilar rápido y sin dolor.