# libuv 1.52.1 — lib C base (de-Alpinizada, Etapa G). compiler=zig-cc (migrado de gcc, matar-gcc 2026-07-16), configure-split, estático.
name    = "libuv"
version = "1.52.1"
license = "MIT"

[source]
tarball = "https://dist.libuv.org/dist/v1.52.1/libuv-v1.52.1.tar.gz"
sha256  = "66d511b9e6e334c0e62279eb234fbfb2b3110b1479c09b95b44c7afca8cff9e7"
patches = ["fix-test-musl.patch"]

[build]
compiler = "zig-cc"
target   = "x86_64-linux-musl"
link     = "static"
flags    = []

[build.phases]
# ⚠ `--with-pic` (2026-10-19): sin él el `libuv.a` no es PIC y **ninguna biblioteca compartida puede
# enlazarlo**. Lo destapó `fcitx5` al enlazar su `libFcitx5Utils.so`:
#     ld.lld: error: relocation R_X86_64_32 cannot be used against local symbol; recompile with -fPIC
#     >>> defined in /usr/lib/libuv.a(libuv_la-proctitle.o)
# Un ejecutable sí puede enlazar un `.a` no-PIC; un `.so` no. Y el `.so` de fcitx5 no es opcional:
# es su núcleo, contra el que enlazan todos los addons.
#
# ⇒ Acá se arregla la LIBRERÍA y no el consumidor, al revés que en `gdk-pixbuf`/`libpng` (2026-08-21,
# decisión del usuario), **y la diferencia es el radio, medido antes de tocar**: `libpng` tiene
# dependientes en cuatro colas y es estático por arquitectura, así que allá se desactivó el único
# `.so` que estorbaba. `libuv` tiene **radio 1 y NINGUNA imagen declarada** — el único dependiente
# es el propio fcitx5 —, así que re-sellarlo no arrastra nada y deja la `.a` usable para cualquier
# consumidor futuro. Sin esto, el siguiente que quiera enlazar libuv desde un `.so` paga el mismo
# viaje.
#
# `--with-pic` es la forma de libtool y la convención de este repo (17 recetas la usan).
configure = './autogen.sh && ./configure --build=$CBUILD --host=$CHOST --prefix=/usr --disable-shared --enable-static --with-pic'
compile   = 'make'
install   = 'make DESTDIR=/out install'