Acerca de los archivos .la en Gentoo

Recientemente compre un equipo un tanto bonito y di por fin el salto a los 64 bits (vayaaa!! ya me habia tardado). Entre los problemas menores que he tenido es usar un google gears no oficial y los drivers binarios de 32 bits para mi impresora que canon nunca se molesto en liberar. Pero si no lo hacia ahora no lo hacia nunca.

El dia de hoy tuve un problema con un archivo, especificamente el archivo libGL.la que por alguna demoniaca razon no me permitia construir algunos paquetes de gtk. Y entre busqueda y busqueda me tope con el blog de Flameeye’s que explicaba el funcionamiento de estos archivos. Del cual traduzco una sección porque me parecio muy interesante. Al final la solucion del problema era facil y fue por otro motivo distinto al que menciona Flameeye’s (un symlink que hacia falta y que por cierto debo reportar).

Aclaro que bibliotecas=bibliotecas de funciones. Lo que en mala traducción llamamos librerias (libreria en ingles es bookstore por cierto :P).

Libtool basicamente es un script generico para bibliotecas que tiene como objetivo esconder la complejidad de utilizar bibliotecas compartidas y hacerlo de una manera portable para cualquier Unix. La traduccón despues de los comerciales jajaja.

….

Cuando un paquete enlaza con libtool por ejemplo con un parametro -lfoo y esa biblioteca fue construida e instalada con libtool. Automaticamente buscara el archivo libfoo.la y lo utilizara para reemplazar la opcion -lfoo con la ruta hacia el archivo de la biblioteca (como parametro de gcc). El problema es que libtool no esta capacitado para reconocer para que arquitectura fue construida la biblioteca y usa la ruta absoluta. En la mayoria de los casos -lfoo seria reemplazado, en un sistema amd64 con la ruta /usr/lib64/libfoo.so.  Nada malo a menos que se este construyendo un binario ELF de 32 bits y entonces fallara (o en mi caso que el ebuild no hacia el symlink y se encontraba en /usr/lib64/opengl/xorg-x11/lib/libGL.la).

¿Pero para que son utilizados los archivos .la en estos dias? Es una buena pregunta, y una que estoy seguro que la mayoria de usuarios y desarrolladores no tienen una respuesta completa. ¿Y son necesarios? Las siguientes dos lineas que se encuentra en todos los archivos .la sugieren que si, pero yo tengo una respuesta diferente.

# Please DO NOT delete this file!
# It is necessary for linking the library.

Empecemos describiendo para que fue diseñado libtool. Construir bibliotecas compartidas en Unix no siempre fue posible, los viejos Unixes no lo soportan, y casi cualquier version de Unix tiene su propia manera para manejar las bibliotecas compartidas. Mientras la mayoria de los Unixes de hoy pueden utilizar la opcion -shared de gcc, testo no siempre fue verdad, y aun existen diferencias en esquemas de nombrado para instancias como Linux, *BSD y s Mac OS X.  libtool abstrae todos estos problemas.

Desafortunadamente, libtool es una enorme y compleja pieza de codigo, y la mayoria de personas que la utilizan no tienen idea como se supone que trabája. El codigo tambien se hace cargo de algunos viejos y hoy en dia no usados casos, que probablemente muchas personas aun sabiendo como funcionan las cosas no sabran porque estan hechas de esa forma.

Una cosa que libtool tiene que trabajar es el hecho que las bibliotecas estaticas son solo archivos, y no contienen metadata respecto a como enlazan con otras bibliotecas (como dependencias). Para esto es que los archivos .la son utilizados. Desafortunadamente libtool no puede entender el caso en que uno no este enlazado archivos estaticos y no necesita de proveer dependencias, al menos en sistemas basados en ELF eso causa uno de los problemas para que uno no pueda prescindir del –as-needed (overlinking).

Pero los archivos .la hoy en dia son utilizados mayormente por programas utilizando libltdl para carga de pluins (como PulseAudio). Esto es de nuevo asi para abstraer diferencias entre el cargador dinamico de distintos sistemas operativos como Unix y Windows por ejemplo.  Esto introduce un poco de redundancia en algunos Linux y *BSD modernos, pero esto no crea tantos problemas como los archivos .la para bibliotecas compartidas.

¿Asi que necesitamos de los archivos .la para enlazar las bibliotecas o no? La respuesta es «no siempre». Si la biblioteca solo intala una copia de si misma, el archivo .la no es necesario en sistemas Linux y *BSD modernos, si la biblioteca instala tambien una copia estatica, podria ser necesario para trabajar adecuadamente con linkeo estatico, ya que la biblioteca puede tener dependencias extra.

En un mundo perfecto, cada biblioteca estatica que necesita dependencias deberia tener su propio archivo .pc para pkg-config, y cada paquete intentando enlazar estaticamente a esa bitlioteca deberia estar utilizando pkg-config –static para obtener las bibliotecas a las que tiene que enlazar. Desafortunadamente no estamos en un mundo perfecto.

Seria bueno si alguien tuviera suficiente tiempo para intentar remover todos los archivos *.la para bibliotecas compartidas (no para plugins) en su sistema, y ver en donde falla al enlazar estaticamente. Yo considero que gastar un poco de tiempo en eso podria ser una muy buena mejora, y un buen paso hacia adelante para tener algun dia buen soporte multilib, pero tengo que esperar por ahora. Si algun usuario considera que esto algo interesante, por favor que me lo deje saber, si veo algun interes en eso intentare dedicarle más tiempo

….

Al final mi error se podia resolver con:

# emerge dev-util/lafilefixer
# lafilefixer –justfixit

Pero es interesante conocer a fondo como funciona mi sistema :). Ni en sistemas operativos aprendi esto xD.

5 Replies to “Acerca de los archivos .la en Gentoo”

  1. Usando Firefox 3.5.5 Firefox 3.5.5 en Gentoo x64 Gentoo x64

    @Luis Alvarado: Tus intentos de chingarme con lo de emo son simplemente pateticos xD. Pero es bueno para que comprobes la efectividad del indexado de google y bailes cumbias en guatemala musical de la felicidad.

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *