Gentoo en una netbook: binhost, EGLFS y distcc para compilar Falkon

2026-11-12 · gentoo, distcc, falkon, eglfs, linux

La idea era simple: instalar Gentoo en una netbook vieja, usar la mayor cantidad de binarios posible y compilar Falkon con EGLFS para que ande sin X11 ni Wayland. El problema es que la netbook tiene un Pentium N3540 (4 núcleos Silvermont), 7.6 GB de RAM y un disco lento: compilar QtWebEngine ahí es una tarde entera.

La solución fue usar el binhost oficial para casi todo y mandar la compilación pesada a otra máquina de la LAN con distcc.

El hardware

Máquina	CPU	RAM	Rol
Netbook	Pentium N3540, 4 núcleos	7.6 GB	Gentoo, OpenRC + elogind
Helper	6 núcleos	16 GB	Arch Linux, distccd

Las dos en 192.168.0.0/24. La netbook es 192.168.0.33 y el helper 192.168.0.143.

1. Base: Gentoo con binhost

Instalé un stage3 amd64 con perfil OpenRC y elogind. Para no compilar todo desde cero configuré el binhost oficial en /etc/portage/binrepos.conf/gentoo.conf:

[gentoo]
priority = 9999
sync-uri = https://distfiles.gentoo.org/releases/amd64/binpackages/23.0/x86-64/

Y en /etc/portage/make.conf lo importante quedó así:

COMMON_FLAGS="-march=silvermont -O2 -pipe"
CFLAGS="${COMMON_FLAGS}"
CXXFLAGS="${COMMON_FLAGS}"

MAKEOPTS="-j10 -l4"

FEATURES="${FEATURES} getbinpkg binpkg-request-signature"
EMERGE_DEFAULT_OPTS="--getbinpkg --autounmask-backtrack=y --keep-going=y"

-march=silvermont es seguro para el N3540. No uso -march=native porque después distcc compila en otra máquina y las instrucciones tienen que coincidir.

Con esto, emerge -v falkon baja la mayoría de las dependencias como .gpkg.tar en vez de compilarlas.

2. EGLFS: la parte que no está en el binhost

El binhost trae dev-qt/qtbase compilado sin el USE flag eglfs. Se puede comprobar rápido: si no existe /usr/lib64/qt6/plugins/platforms/libqeglfs.so, Falkon no va a poder arrancar en una TTY sin servidor gráfico.

Lo agregué en /etc/portage/package.use/qt:

dev-qt/qtbase eglfs

Y reconstruí QtBase desde fuente:

emerge -av --changed-use dev-qt/qtbase

Eso obliga a compilar QtBase localmente (o con distcc), pero es una sola vez. Después verificamos que el plugin exista:

ls /usr/lib64/qt6/plugins/platforms/libqeglfs.so

Para probar Falkon desde una TTY, con el usuario en el grupo video y con acceso a /dev/dri:

QT_QPA_PLATFORM=eglfs \
QT_QPA_EGLFS_INTEGRATION=eglfs_kms \
QTWEBENGINE_DISABLE_SANDBOX=1 \
falkon

QTWEBENGINE_DISABLE_SANDBOX=1 es un parche para probar; si podés, dejá el sandbox activado.

3. distcc: el helper

En el helper (Arch Linux) instalé distcc y lo dejé escuchando solo en la LAN. En /etc/conf.d/distccd:

DISTCC_ARGS="--allow 192.168.0.0/24 --jobs 6 --nice 5"

systemctl enable --now distccd

Abrí el puerto 3632/tcp solo para 192.168.0.0/24.

distccd ejecuta comandos que le manda el cliente. No lo expongas a Internet ni lo dejes con --allow 0.0.0.0/0. La red tiene que ser de confianza.

4. distcc: el cliente Gentoo

En la netbook:

emerge -av sys-devel/distcc

/etc/distcc/hosts:

192.168.0.143/6
localhost/4

El /6 son los 6 jobs del helper y localhost/4 los 4 núcleos de la netbook. Uso TCP, no el modo SSH de distcc. ¿Por qué? Porque con FEATURES=userpriv Portage compila como el usuario portage, y el modo SSH necesitaría una clave SSH para ese usuario. TCP es más simple y distccd ya filtra por --allow.

En /etc/portage/make.conf agregué:

MAKEOPTS="-j10 -l4"
FEATURES="${FEATURES} distcc"
DISTCC_DIR="/var/tmp/portage/.distcc"

Y creé el directorio de estado con el dueño correcto:

mkdir -p /var/tmp/portage/.distcc
chown -R portage:portage /var/tmp/portage/.distcc

-j10 = 6 jobs remotos + 4 locales. -l4 limita la carga local a 4 para que la netbook no se arrastre.

Importante: las versiones de GCC y binutils del cliente y del helper deberían coincidir. En mi caso el test funcionó con gcc 16.2.1_p20260926 en Gentoo y gcc 16.2.1 20260810 en Arch, pero si aparecen errores raros, igualá las versiones o compilá esa parte localmente.

5. Verificar que los trabajos lleguen

Primero, ver qué hosts ve el cliente:

distcc --show-hosts

Después, una compilación de prueba con salida verbosa:

printf '#include <stdio.h>\nint main(void){puts("ok");return 0;}\n' > /tmp/t.c
DISTCC_VERBOSE=1 distcc gcc -c /tmp/t.c -o /tmp/t.o

Si todo anda, aparece algo así:

compile /tmp/t.c on 192.168.0.143/6 completed ok

En el helper se puede confirmar de tres formas:

journalctl -u distccd -n 5
ss -tn | grep ':3632'
ps -eo pid,comm,args | grep '[c]c1plus'

Un log típico del helper:

distccd[476]: (dcc_job_summary) client: 192.168.0.33:39884 COMPILE_OK \
  ... x86_64-pc-linux-gnu-g++ .../function_get_path_info.cc

Y desde la netbook, mientras compila:

DISTCC_DIR=/var/tmp/portage/.distcc distccmon-text 2

6. Compilar Falkon

Con todo configurado:

emerge -v falkon

En mi caso dev-qt/qtwebengine se compiló desde fuente: el binhost lo trae con bindist, mi perfil usa -bindist, y además QtBase ya lo había tenido que reconstruir por eglfs. QtWebEngine es la parte pesada, así que ahí es donde se nota distcc.

Durante el build se ve el wrapper de distcc en acción:

/usr/lib/distcc/bin/x86_64-pc-linux-gnu-g++ ...

y en el helper aparecen los cc1plus remotos. Los trabajos llegaron bien: COMPILE_OK y conexiones establecidas al puerto 3632.

Notas y problemas comunes

binpkg-request-signature: si empezás a generar tus propios binarios con FEATURES=buildpkg, o los firmás o sacás ese feature.
Unity builds: QtWebEngine usa archivos de traducción enormes; en esos casos distcc ayuda menos porque hay pocos archivos para repartir.
Linking: el enlazado final se hace en la netbook; distcc solo acelera la compilación.
Si distcc falla: probá FEATURES="-distcc" para aislar si el problema es del cluster o del paquete.
Firewall: el helper solo debe aceptar 3632/tcp desde la LAN.

La netbook no se va a convertir en un servidor de compilación, pero con binhost + distcc + un poco de paciencia, Falkon con EGLFS se puede compilar sin dejar la máquina colgada una tarde entera.