Gestión de bibliotecas compartidas en el árbol de portes

Qué son las reglas numéricas de las bibliotecas compartidas

Cuando se enlaza un programa, el enlazador ld embebe esa información en el binario que se genera. Esto se puede ver con ldd. Más tarde, cuando se ejecuta este programa, el enlazador dinámico ld.so utiliza esa información para encontrar la biblioteca dinámica pertinente:

• Requiere una biblioteca con la numeración superior exactamente igual.
• Requiere una biblioteca con la numeración inferior igual o mayor.

Las reglas para las bibliotecas compartidas son bastante simples.

• Si se añaden funciones a la bibliotecas, es necesario incrementar el número inferior de la biblioteca: un programa que necesite esas funciones no tiene otro modo para requerirlas que no sea el de pedirlas de forma explícita para, por lo menos, esta versión.
• Si el API actual cambia, o sea, si se altera la firma de cualquier función, o si las secuencias de llamada ya no son válidas, si un tipo cambia de forma incompatible, el número superior se debe incrementar.
• Esto incluye la eliminación de funciones antiguas. Cualquier eliminación de funciones debería ir acompañada por un incremento en el número superior.

Algunas veces sucede que una biblioteca está escrita en varios ficheros, y las funciones internas son visibles para permitir la comunicación entre esos ficheros. Esos nombre de funciones suelen empezar con un guión bajo, y no son parte del API.

Nótese que el esquema de nombres de las bibliotecas es ubicuo en las plataformas de OpenBSD, tanto si el formato es ELF como a.out.

Cambios en los portes para obtener nombre correctos

Si intenta cambiar el nombre de la biblioteca más tarde para ajustar el número de versión, no funcionará: las bibliotecas ELF usan magia adicional para el nombre interno de la biblioteca, por lo que debe enlazar desde la primera vez con la versión correcta.

Por otra parte, recuerde que puede anular y cambiar variables de Makefile desde la línea de órdenes, usando MAKE_FLAGS en el fichero Makefile del porte. Esto le será de gran utilidad en algunos portes, como por ejemplo los basados en libtool, ya que proveen de una de estas variables de versión por cada biblioteca que crean.

El mejor modo de manejar los portes basados en libtool es configurar la variable USE_LIBTOOL=Yes. Esto activa la versión de libtool presente en el árbol de portes, y se encarga automáticamente de la mayoría de los detalles:

• libtool mira en SHARED_LIBS y reemplaza automáticamente los números de versión.
• libtool produce un registro de biblioteca compartida en el fichero ${WRKBUILD}/shared_libs.log que puede ser incluido directamente en el Makefile del porte.

Intente poner todas las bibliotecas visibles en /usr/local/lib

• En el momento de la compilación, ld usa señalizadores -L para configurar rutas en las que busca bibliotecas. En cuanto encuentra una biblioteca que coincide con sus requisitos, para de buscar.
• En el momento de la ejecución, ld.so usa la información guardada mediante ldconfig para encontrar la biblioteca requerida.

Para resolver esas bibliotecas en el momento de la ejecución, se proveerá un enlace llamado /usr/local/lib/libqt.so.1.45 y otro llamado /usr/local/lib/libqt.so.2.31. Esto será suficiente para satisfacer a ld.so.

Enlazar un programa usando qt1 con ld -o program program.o -L/usr/local/lib -lqt es un error. Este código asume que qt.2.31 no ha sido instalado, lo que es una presunción errónea.

Estos trucos sólo son necesarios en casos especiales en los que se den bibliotecas para las que se necesite proveer de un periodo de transición entre versiones. Por lo general, bastará con asegurarse de que la biblioteca aparezca en /usr/local/lib.

Cómo escribir correctamente las dependencias de las bibliotecas

        LIB_DEPENDS += ::x11/gtk+
        WANTLIB += gtk.>=1.2,gdk.>=1.2

Además, especificar las bibliotecas estáticas en una línea de WANTLIB no es un error. WANTLIB es evaluado por completo en el momento de la compilación de un paquete: el paquete resultante tendrá la información sobre dependencias de bibliotecas embebido, en forma de líneas para ld.so, que contienen el número superior.inferior que fue usado para su compilación, y nada para las bibliotecas compartidas.

También debe proveer de RUN_DEPENDS si un porte requiere algo más que compilar enlazando a una biblioteca. Esto permitirá al porte compilar correctamente en arquitecturas que no tengan soporte para bibliotecas compartidas.

De hecho, proveer líneas LIB_DEPENDS incluso para bibliotecas estáticas es una buena idea: esto simplificará la acutalización del porte si una cierta dependencia pasa de biblioteca estática a biblioteca compartida.

La líneas WANTLIB deben especificar las mismas rutas que se utilizan para ld. Con el ejemplo anterior, un fragmento de dependencia típico de qt2 dice: WANTLIB += lib/qt2/qt.=2. Esto permite a la dependencia comprobar el código para poder hacer lo correcto si se encuentra con varias versiones de la misma biblioteca.

Cómo actualizar los portes correctamente

• Asegúrese de que los números mayor.menor de las bibliotecas compartidas sean los correctos.
• Verifique todos los portes que dependan de su porte. Verifique que compilen correctamente con sus cambio. Notifique de la actualización a los mantenedores correspondientes, para que éstos puedan verificar que sus portes todavía funcionan bien.
• Puede que tenga que ajustar las dependencias de portes WANTLIB y LIB_DEPENDS. Si introduce nuevas bibliotecas compartidas, preste atención a los BUILD_DEPENDS que tengan que ser convertidos en LIB_DEPENDS.
• Siempre que introduzca un nuevo porte debe verificar que no esté creando una biblioteca que entre en conflicto con otra ya existente: las bibliotecas de dos portes con el mismo número son mortales, debido a que sus esquemas de enumeración de versiones no pueden coincidir. Debe intentar resolver esta situación con el programa del autor (por ejemplo, una biblioteca que se llame libnet es un mal comienzo).
• Para obtener información más amplia, diríjase a la guía de actualización de portes.