bluez b3:6036ab1585ce2af12e7596edd16709d1baa906f8c0ca816aed44957a038fbd66
11/11 ejecutables `statically linked` · `bluetoothctl: 5.87` corre · 31 ficheros (no se perdió nada)
El sello de ayer decía `static` y salía con los ONCE ejecutables dinámicos; el audit del cron lo
marcó esa misma noche (docs/state/static-audit.txt, 2026-09-12T21:04Z) y dejó el veredicto global
en rojo: 715 honestas y las dos nuevas mintiendo. Acá se puede ser estático de verdad —el artefacto
NO trae ningún plugin .so, o sea que nadie hace dlopen (a diferencia de cmus)— así que el arreglo
es el arreglo, no una re-declaración.
Dos mitades, y la segunda no se ve venir:
1. `LDFLAGS=-all-static` en compile **Y** en install: bluez enlaza con libtool, que lee el `-static`
del lab como «preferí los .a de libtool» y además RELINKEA al instalar.
2. `LIBS=-lncursesw`. Con -all-static el enlace de bluetoothctl corta con
`undefined symbol: tgoto ... in archive /usr/lib/libreadline.a`: readline usa termcap y su
readline.pc lo declara en `Requires.private: ncurses`, que **sólo se expande con
`pkg-config --static`**. El configure de bluez busca readline con AC_CHECK_LIB, no con
pkg-config ⇒ la transitiva nunca entra. En dinámico no se nota: la resuelve el loader.
Y se QUITA el `runtime = ["readline-shared"]` que se había añadido horas antes: hacía falta
mientras bluetoothctl era dinámico, y con el estático pasó a ser la mentira simétrica —declarar una
dep que no se usa—. No mueve el hash (las deps de runtime no entran en hash_inputs).
Se descubrió CORRIENDO los binarios, no auditando las recetas, y el hash NO se mueve (las deps de
runtime no entran en hash_inputs): los artefactos sellados siguen valiendo.
cmus/cmus NEEDED libncursesw.so.6 ⇒ runtime = ["ncurses-shared"]
bluez/bluetoothctl NEEDED libreadline.so.8 ⇒ runtime = ["readline-shared"]
Las canónicas `ncurses` y `readline` del corpus son `--without-shared`/sólo `.a`, así que sin
declarar la variante `-shared` esos `.so` no viajan en la imagen y el binario muere en el loader.
Es la MISMA fuga que el perfil de sway ya pagó con zlib/expat/libffi, y no la ve ningún auditor de
recetas: sólo `readelf -d` sobre el artefacto, o ejecutarlo.
El reparto de bluez era el peor posible: `bluetoothd` sale con `libc.so` a secas y habría
arrancado, y la herramienta con la que se emparejan los dispositivos habría sido la que no.
Comprobado con scripts/provee.py: los dos sonames SÍ los publica el corpus
(corpus/ncurses-shared, corpus/readline-shared) ⇒ no hay NEEDED colgante, faltaba la declaración.
bluez b3:21bee949122f770a319b806b83d23fa2bddc958252f6de7e27fffa5a75a3315a (28 MB, 31 ficheros)
Con esto queda cerrado el punto 8 de PUBLICABLE (docs/20): «cups y bluez».
El fallo del primer intento vale más que la receta: con [deps] build=["glib", ...] el configure
corta con «Package 'libpcre2-8', required by 'glib-2.0', not found». No falta una dep de bluez:
faltan las TRANSITIVAS del .pc de glib. Un enlace estático resuelve la cadena entera en el punto de
enlace, así que pcre2/libffi/zlib hay que materializarlas aunque bluez no las nombre — es el mismo
juego de cuatro que ya declaran cairo, appstream y adwaita-hello, y que nadie había escrito por qué.
Perillas leídas del «configure --help» del tarball pineado:
- --disable-obex: obexd pide libical, y libical existe SÓLO en incoming-gnome. Una receta del
corpus resuelve sibling-first y después el catálogo PADRE, nunca una cola hermana ⇒ desde acá no
se alcanza. Encenderlo exige promover libical, que es otra unidad de trabajo.
- --disable-manpages: las genera rst2man (docutils); no es receta.
- --disable-cups: el backend de impresión por Bluetooth. cups YA es receta desde hoy, o sea que
esto se puede encender — queda anotado como lo próximo, no como olvido.
Declara [[service]] bluetoothd; el exec VERIFICADO contra el artefacto: /usr/lib/bluetooth/bluetoothd.
Y va escrito que esto no enciende el bluetooth de nadie: falta dbus vivo y que el perfil lo habilite.
Sergio