Files
takana/recipes
Sergio 22bf487b1a gcc-libs: las librerías de ejecución que faltaban (b3:aa605af4)
libstdc++.so.6 (20.850.968 bytes) y libgcc_s.so.1 (824.776), construidas desde
el tarball de GCC 15.2.0 — la MISMA versión del lab, porque firefox se enlaza
contra la libstdc++ compartida de ese gcc y otra versión traería de vuelta el
mismo fallo disfrazado. sha512 del tarball verificado byte a byte contra el
APKBUILD de Alpine.

Tres decisiones que no son de estilo:

  --disable-symvers   Alpine lo pasa. El versionado cambia la tabla de símbolos;
                      nuestros binarios se enlazaron contra la libstdc++ SIN
                      versionar del lab.
  link = "dynamic"    hammer inyecta LDFLAGS=-static por defecto y acá el
                      producto ES una librería compartida: con el default no
                      saldría ni un .so. Misma perilla que apagaba los threads
                      de openssl, vista desde el otro lado.
  --disable-bootstrap Sólo `all-target-libgcc all-target-libstdc++-v3`. GCC
                      entero multiplica el tiempo por cinco para tirar el
                      compilador a la basura.

Los guardianes se ganaron el sueldo en las dos primeras corridas:

  1ª  «!! falta libstdc++.so.6» — y las librerías estaban perfectas: GCC instala
      en /usr/lib64 porque su t-linux64 fija MULTILIB_OSDIRNAMES=../lib64, y
      --disable-multilib NO lo apaga. Un .so impecable en el directorio que el
      loader no mira es EXACTAMENTE el fallo que esta receta viene a arreglar,
      un directorio más allá. Se normaliza a lib en el install.
  2ª  «!! no definen los símbolos» — y sí los definían. --disable-symvers apaga
      el versionado de libstdc++, pero libgcc tiene su PROPIO libgcc.map y
      versiona igual: nm los imprime como _Unwind_Backtrace@@GCC_3.3 y el grep
      anclado al fin de línea no los veía. El fallo era del guardián. Verificado
      contra el libgcc_s.so.1 DEL LAB —el que satisface a firefox hoy— y
      coinciden hasta en la etiqueta de versión.

gmp/mpfr/mpc ya existían pero sólo en recipes/incoming-*, con DOS variantes cada
una. Promovidas las de incoming-kde y no las de cosmic: la terna tiene que ser
internamente coherente porque mpc enlaza su .so contra las otras dos, y con las
de cosmic (estáticas sin PIC) muere en «relocation R_X86_64_32 ... recompile
with -fPIC». La de kde va con link=dynamic las tres y además ya estaba SELLADA
entera, así que la promoción no costó ni un build.
2026-09-06 20:08:53 +00:00
..