Desarrollo Portable con GNU Autotools

La mayoría de programas hace uso de algunas facilidades proporcionadas por el sistema operativo en su kernel o sus librerías. Por ejemplo, muchos sistemas derivados de BSD proporcionan la rutina usleep() que permite hacer pausas con precisión de microsegundos. El estándar POSIX, sin embargo, define la función nanosleep() que permite hacer una operación similar. Dado que es muy probable que las futuras plataformas se adscriban al estándar POSIX, concluimos que resulta preferible el empleo del moderno nanosleep().

Sin embargo, la solución óptima consiste en desarrollar el programa de modo tal que se pueda "configurar" para que utilice preferentemente el moderno nanosleep(), y de no ser esto posible, el obsoleto usleep(). Conseguir esta flexibilidad no es tarea sencilla.

El GNU Build System cuenta con el programa autoconf entre sus herramientas. Como veremos, este programa genera un script (llamado configure) que se encarga de analizar las facilidades disponibles (como usleep() vs nanosleep()) en la plataforma en la que se pretende compilar la aplicación, lo cual es una gran ayuda a fin de hacer más portable a nuestro programa.

Cualquier aplicación no trivial consta de un número considerable de archivos de diversos tipos, repartidos en varios directorios. Todos estos componentes deben integrarse adecuadamente para conformar las librerías, los ejecutables, los archivos auxiliares (datos, imágenes, etc.) así como la documentación.

En los sistemas tipo Unix se recurre a la herramienta make (que se describe en el apéndice A) para automatizar todo este proceso. Esta herramienta requiere que el desarrollador escriba un archivo de comandos con una sintaxis especial (el Makefile) la cual especifica con cierto detalle qué es lo que hay que hacer para construir la aplicación.

Lamentablemente, la escritura de un Makefile "completo" ^[5] es un proceso relativamente largo y propenso a errores (salvo en programas triviales.) A tal efecto, el GNU Build System proporciona una herramienta llamada automake que permite al desarrollador escribir una especificación más sencilla acerca de lo que quiere construir. A diferencia del Makefile, la especificación de automake (que se denomina Makefile.am) sólo requiere especificar 'qué' se quiere construir, y no 'cómo' se debe construir.

En conclusión, el GNU Build System no sólo mejora la portabilidad, sino que simplifica la especificación de la construcción de las aplicaciones no triviales.

Las dos secciones anteriores discutieron facilidades que atañen únicamente a los desarrolladores que crean aplicaciones portables. En esta sección nos referimos a lo que tiene que hacer el usuario/instalador/administrador que obtiene el paquete del desarrollador, y pretende utilizarlo en su plataforma (que posiblemente es distinta a la del desarrollador.)

El GNU Build System promueve la distribución de paquetes de código fuente, los cuales deben ser "configurados", "construidos" e "instalados" por los usuarios finales instaladores. Esto involucra normalmente tres pasos (obviando el desempacado del paquete):

El último paso (make install) probablemente debe realizarse con el usuario administrador (root) si se instalarán archivos en directorios del sistema (por omisión, todo el software generado con el GNU Build System se instalará a partir de /usr/local.)

Este proceso es el mismo para todo paquete generado con el GNU Build System, y al estar ampliamente difundido facilita el trabajo a los usuarios/instaladores.

Siempre es posible especificar un conjunto de opciones a configure, las cuales se pueden obtener mediante:

Ciertas opciones están presentes en casi todos los paquetes; por ejemplo, una opción muy popular corresponde al directorio en el cual se instalará el software tras ser compilado, mediante make install (como indicamos, por omisión es /usr/local):

Con esto, al ejecutar make install, el software se instalará en un subdirectorio de nuestro propio "Home Directory", lo cual tiene la ventaja de no requerir permisos de escritura adicionales.

Partimos de un nuevo directorio en blanco en el que depositaremos sólo el código fuente (descartamos nuestro Makefile):

A cada archivo fuente de lenguaje C le agregaremos las siguientes tres líneas:

Con esto, el programa queda convertido en:

Este archivo se emplea para especificar las características generales del paquete así como los tests de portabilidad entre plataformas. Lo que sigue se puede considerar una plantilla básica para muchos proyectos:

Un poco más abajo, al hablar de autoconf, explicaremos su contenido.

El archivo Makefile.am corresponde a una especificación acerca de lo que se pretende construir. En nuestro caso se trata de un programa llamado ejemplo1, el cual consta de un archivo fuente ejemplo1.c, y se enlaza con la librería ncurses:

En este punto tenemos sólo los siguientes archivos:

Eso es todo lo que necesitamos escribir. A continuación las herramientas GNU harán el resto del trabajo, para lo cual ejecutaremos aclocal, autoconf, autoheader y automake (de preferencia en ese orden.)

El programa aclocal examina el archivo configure.ac y analiza si se requieren macros no incorporadas en autoconf (por ejemplo, las macros relacionadas con automake que tienen la forma "AM*") las cuales son agregadas en el archivo auxiliar aclocal.m4. También se emplea en ciertos proyectos para proporcionar macros personalizas del desarrollador.

El programa autoconf generará el script "configure" y quizá otros archivos auxiliares:

Tal como indicamos anteriormente, autoconf requiere que el archivo configure.ac contenga al menos de las macros AC_INIT y AC_OUTPUT. La macro AC_INIT (que debe estar al principio de configure.ac) recibe los parámetros:

1- Nombre del paquete completo

2- Versión del paquete ^[10]

3- Dirección email para reporte de bugs

Nótese que se ha rodeado estos argumentos con los símbolos [ y ] correspondientes al "entrecomillado" de M4. Estrictamente, éstos no se requieren cuando el texto es simple, pero son obligatorios cuando el argumento consiste en una invocación a otra macro.

Para los conocedores de M4: Normalmente, M4 emplea los caracteres "`" y "'" para "entrecomillar". En las herramientas que estamos viendo, éstos se han cambiado por [ y ], lo cual se explica en la documentación oficial de autoconf:

Los parámetros de AC_INIT se podrán apreciar por el usuario instalador cuando ejecute:

Todo archivo configure.ac debe terminar con AC_OUTPUT.

La macro AC_PROC_CC instruye a autoconf para programar un test de existencia del compilador de lenguaje C y siempre se debe incluir si el proyecto contiene al menos una fuente de lenguaje C. Finalmente, la macro AC_CONFIG_FILES permite especificar qué archivos se generarán al ejecutarse configure, que en nuestro caso será sólo el Makefile. Un poco más adelante veremos las macros aún no explicadas.

Como sabemos, este programa genera el archivo de definiciones de preprocesador config.h.in, el cual se usa más adelante para generar a config.h.

Son imprescindibles. Si Ud. olvida crearlos la ejecución de automake (el siguiente paso) fallará. Su contenido por ahora no nos interesa ^[11], así que los creamos en blanco:

La opción '-a' solicita a automake que genere algunos archivos complementarios que son necesarios para etapas posteriores del proceso de generación del paquete.

Tal como se aprecia, hemos llenado nuestro humilde directorio de fuentes con una cantidad increible de archivos autogenerados:

En este punto el proyecto está listo para que se ejecute ./configure, el cual generará un Makefile específico para nuestro sistema (y otros archivos complementarios.)

Como se indicó, automake requiere que configure.ac contenga la macro AM_INIT_AUTOMAKE. Esta macro recibe dos parámetros que corresponden al nombre del paquete y la versión del paquete a ser distribuido. En nuestro caso, los parámetros indicados implican que el paquete a generarse (lo veremos más adelante) se llamará ejemplo1-1.0.tar.gz (nombre-version.tar.gz.)

Es muy recomendable (especialmente para los desarrolladores que utilizan herramientas GNU) lanzar configure desde un nuevo directorio al que llamaremos "de construcción", en vez de emplear el mismo directorio "de fuentes". Esto ayuda a detectar ciertos errores en las rutas y de paso no se contamina más nuestro directorio de fuentes con los subproductos del proceso de construcción ^[12]:

Nótese que se ha generado (al fin') un Makefile. Este Makefile hace referencia al directorio que contiene las fuentes (que no están aquí.) Sin embargo, todos los archivos que se generen como parte de proceso de compilación se almacenarán en este "directorio de compilación". También podemos apreciar la creación del antes mencionado config.h.

Si Ud. revisa el Makefile notará que está muy lejos de aquel que hicieramos manualmente en la versión "no portable".

Apreciamos que se ha generado el ejecutable ejemplo1.

Por omisión los programas se instalarán bajo /usr/local, lo cual normalmente requiere ser administrador para tener permiso de escritura:

Como se aprecia, el ejectuable se ha copiado a /usr/local/bin, el cual debería estar en el PATH de los usuarios para facilitar su ejecución.

Es evidente que si empleamos un lenguaje de programación disponible en una única plataforma P1, la portabilidad se restringe tremendamente; el llevar la aplicación a la plataforma P2 típicamente involucra una reescritura total, quizá en otro lenguaje de programación.

Un ejemplo conocido lo constituye la multitud de lenguajes inventados y reinventados por Micros*ft, los que obligan a sus programadores y usuarios a emplear exclusivamente su plataforma Wind*ws.

De forma similar, es muy probable que una aplicación no trivial utilice las facilidades de diversas librerías proporcionadas por el Sistema Operativo o por terceros. En términos generales, siempre se debe tratar de utilizar librerías a fin de no volver a escribir y depurar código que ya ha pasado por este proceso; sin embargo, es conveniente elegir librerías que están disponibles en múltiples plataformas a fin de que nuestra aplicación no requiera modificaciones por este concepto al ser trasladada a dichas plataformas. En particular, es extremadamente recomendable que las librerías utilizadas sean de código abierto, las cuales en caso de necesidad pueden ser portadas por nosotros mismos a cualquier otra plataforma.

Ciertos lenguajes de programación están implementados en múltiples plataformas, pero lamentablemente tienen diversas incompatibilidades entre sí. En otras palabras, existen diversos "dialectos" más o menos parecidos, pero que convierten la adaptación de aplicaciones en una pesadilla. Un ejemplo clásico es el lenguaje Basic que está disponible en decenas de plataformas, y prácticamente ninguna es igual a la otra. Esto quiere decir que cualquier programa no trivial en Basic requiere de una fuerte dosis de reescritura para llevarse de P1 a P2.

Afortunadamente algunos lenguajes han sido formalmente estandarizados a fin de proporcionar un marco seguro de portabilidad. Uno de los ejemplos más conocidos corresponde al lenguaje C, el cual actualmente es un estándar ANSI/ISO (lo mismo que el C++.) Las organizaciones de estandarización proporcionan referencias que los implementadores deben seguir y así garantizan un comportamiento uniforme entre plataformas.

En particular, los estándares de C y C++ permiten desarrollar muchas aplicaciones (pero no todas) de manera totalmente portable para cualquier plataforma que disponga de un compilador "estandarizado". El lenguaje Java permite hacer programas aún más portables en tanto sus estándares son más estrictos y cubren muchos aspectos que van más allá del lenguaje, lo que deja muy poco a criterio del implementador (como si ocurre con C y C++.)

Esto es una consecuencia lógica de lo anterior. Muchas veces estamos empleando un lenguaje bien estandarizado, pero la documentación nos señala la posibilidad de emplear "extensiones" para ahorrarnos cierto trabajo. Muchas veces no está bien documentado que se trata precísamente de "extensiones" que minan la portabilidad, o simplemente la gente no le da la debida importancia a este hecho.

El caso es que todas estas extensiones deben ser bien identificadas y su uso debe evitarse en lo posible. Si por algún motivo se decidiera el empleo de éstas, deberíamos al menos tratar de asegurarnos de que será posible removerlas en el futuro. En particular, el código que depende de aquellas debe ailsarse a fin de facilitar su futura reescritura.

Como indicamos antes, muchas aplicaciones no pueden escribirse empleando exclusivamente los aspectos estandarizados de un lenguaje de programación particular. Típicamente se requiere de librerías de terceros, así como de llamadas específicas del sistema operativo que se está utilizando.

En estos casos, el código fuente en cuestión no es portable; sin embargo, una manera muy efectiva para que la aplicación en su conjunto sea altamente portable consiste en aislar aquel código que necesariamente se tendrá que reescribir en el futuro al momento de portar. Este código bien aislado se suele almacenar en una librería, la cual se intenta mantener lo más reducida posible a fin de reducir lo que potencialmente habrá que reescribir.

Incluso si nuestro programa ha sido codificado respetando los estándares de portabilidad, es frecuente que se requiera de ciertos cambios relativamente simples (aunque numerosos) cuando se intente portar a otra plataforma. Esto ocurre por diversos motivos: las diversas plataformas respetan o ignoran los diversos estándares, o los cumplen sólo parcialmente; los estándares evolucionan con el tiempo, y no especifican absolutamente todo; los vendedores de las plataformas introducen cambios (y errores) a fin de mejorar sus ofertas, etc.

Las tres primeras líneas incluyen condicionalmente el archivo config.h. Como se indicó anteriormente, éstas deben incluirse al inicio de todos los archivos de código fuente C/C++ de nuestra aplicación.

El archivo config.h contiene una serie de macros producto del análisis que realiza configure de la plataforma donde se desea construir la aplicación. De no utilizarse las herramientas GNU, el archivo config.h sencillamente no existiría y su inclusión en el código fuente generaría un error de precompilación; por esto, su inclusión es condicional mediante la macro HAVE_CONFIG_H, la cual es definida por el Makefile generado con herramientas GNU. Si Ud. no comprende el significado de estas directivas, es imprescindible que consulte la documentación del precompilador del lenguaje C/C++ (en los libros de C/C++.)

Posteriormente (línea 4) tenemos la inclusión del header ncurses.h. Para quien no está informado, Curses es una librería disponible en prácticamente todos los sistemas Unix y tiene entre sus objetivos facilitar el desarrollo de aplicaciones que hacen uso extensivo de la pantalla completa de un terminal (por ejemplo, hacer saltar el cursor, cambiar los colores del texto, etc.)

Existen diversas implementaciones comerciales de la librería Curses disponibles en los sistemas Unix comerciales. En los sistemas de código fuente abierto (como Linux) se suele emplear una implementación denominada "New Curses" o "ncurses" que tiene prácticamente la misma funcionalidad.

Nuestro programa ha asumido (correctamente para el sistema que estoy utilizando en este momento) que está disponible el header "ncurses.h" en el directorio estándar de headers (normalmente /usr/include.) Sin embargo, la observación y 'experiencia' con otros sistemas indica que esto no es muy portable. En particular, los sistemas Unix comerciales suelen disponer de un header equivalente llamado "curses.h". Asimismo, es posible encontrar distribuciones de Linux antiguas que incluyen a "ncurses.h" en un directorio no estándar (frecuentemente /usr/include/ncurses.) Y siguiendo esta última idea, podríamos 'conjeturar' que hay sistemas Unix comerciales que incluyen a "curses.h" en su propio directorio no estándar /usr/include/curses. Por lo tanto, solicitaremos a autoconf (mediante configure.ac) que programe cuatro tests de existencia para el archivo cabecera "Curses/Ncurses".

Incluso si la plataforma destino no dispone de ninguno de los headers posibles para "Curses/Ncurses" y el programa no se puede construir, es mucho mejor que configure proporcione un mensaje tal como:

A que el usuario final instalador obtenga lo siguiente (quizá tras haber perdido mucho tiempo compilando otros módulos):

¿Qué puede hacer un instalador que no es desarrollador con este mensaje? …​de seguro quejarse con el autor del programa.

A fin de programar los tests mencionados, podemos agregar lo siguiente a configure.ac:

Esta directiva verifica la existencia de los headers especificados (en el mismo orden) y define una macro para cada uno de aquellos cuya existencia se comprueba. Suponiendo -por ejemplo- que en cierta plataforma se encuentran los headers /usr/include/curses.h y /usr/include/ncurses/ncurses.h (es decir, el segundo y tercer headers de la lista), entonces en config.h se definirían las macros:

Y no se definirán macros correspondientes a los otros headers inexistentes.

Sin embargo, dado que nos basta con uno solo de estos headers, podríamos acelerar un poco la ejecución de configure si le solicitamos que termine este test tan pronto encuentre uno de los headers de la lista:

break es un comando del shell que interrumpe loops, y se emplea para finalizar el loop de configure que itera entre los headers de la lista.

Con el fin de utilizar los descubrimentos de configure plasmados en macros de config.h, debemos añadir a nuestro programa lo siguiente:

Por favor asegúrese de comprender esto antes de proseguir; como indicamos, esto son únicamente directivas del preprocesador de lenguaje C/C++.

Este header es requerido para la declaración de usleep(). Podemos agregar en configure.ac:

Sólo a modo de ilustración, podemos instruir a configure para emitir un mensaje si se encuentra dicho header, y otro mensaje si no se encuentra:

Si consideramos imprescindible la presencia de este header, podemos forzar a que configure se detenga al no hallarlo. Para esto, empleamos AC_MSG_ERROR:

Recordar que en tanto estamos utilizando macros como argumentos de otra macro, es imprescindible "entrecomillar" los argumentos de éstos con '[' y ']'.

Como primera aproximación, presentemos un test para verificar la disponibilidad de esta función en las librerías estándares:

Si configure verifica la disponibilidad de dicha función, se generará (en config.h) la macro:

Que puede ser convenientemente utilizada en nuestro código fuente.

Sin embargo, anteriormente se comentó que usleep() no era la función más adecuada para nuestro propósito (de hecho, se considera obsoleta.) Por el contrario, el estándar POSIX recomienda en su lugar el empleo de nanosleep(), la cual tiene mayores posibilidades de estar implementada en las plataformas del futuro. Por tanto, podemos modificar nuestro test del siguiente modo:

Esto verificará la disponibilidad de nanosleep() y de hallarse, definirá la macro correspondiente (HAVE_NANOSLEEP) y continuará con otros tests. Sólo de no encontrarse disponible se procederá al test de usleep(). Nótese que gracias a 'break' a lo más una de éstas estará disponible.

Esto trae dos consecuencias. En primer lugar, tenemos que considerar ahora el header que declara a nanosleep(); en tanto la documentación indica que se trata de time.h, debemos proceder a programar un test para validar su existencia:

La segunda consecuencia corresponde a las modificaciones necesarias en el código fuente a fin de poder emplear nanosleep() o usleep(). La primera emplea una estructura especial de tipo timespec para especificar el tiempo de retardo, mientras que la segunda sólo requiere un argumento unsigned long correspondiente a los microsegundos de retardo. A continuación una primera versión modificada del código fuente que hace uso de todo lo anterior:

Nótese que no hay riesgo de invocar un doble retardo (un nanosleep() seguido de un usleep()) pues como indicamos, a lo más una de éstas funciones estará definida. Por otro lado, no es riesgoso incluir ambos headers time.h y unistd.h aun si sólo uno de ellos será aprovechado.

Así como hay diversas posibilidades para el header de Curses/Ncurses, también se requiere especificar la librería adecuada para el momento del enlace. Esto se especificó manualmente en el archivo Makefile.am mediante:

Esto significa que el compilador al momento de generar el ejecutable intentará enlazar con la librería "libncurses.*".

Como es de esperarse, en sistemas Unix comerciales el enlace deberá hacerse con la versión comercial de curses: "libcurses.*". Para soportar ambas posibilidades, en primer lugar eliminemos la directiva ejemplo1+LADD de Makefile.am que asumía la versión Ncurses:

Y añadiremos el siguiente test a configure.ac:

Esta macro requiere como primer argumento el nombre de una función que debe estar en la librería que se está buscando. En nuestro caso, Curses/Ncurses proporciona muchas funciones, de las cuales he elegido a initscr() (se puede elegir cualquiera ^[14].) Con esta información, configure verifica si es posible crear un programa que invoque a dicha función conforme se enlaza con cada una de las librerías proporcionadas en el segundo argumento. Tan pronto se encuentra ésta librería, se agrega al contenido de la variable especial LIBS, la cual en el Makefile especifica las librerías a enlazar con todos los programas.

El tercer argumento corresponde a una acción a realizar cuando se encuentra una librería válida (en nuestro caso, no tenemos nada que hacer), mientras que el cuarto argumento corresponde a qué hacer si NINGUNA de las librerías resulta ser útil (o no se encuentran.) En este caso hemos especificado un mensaje de error (que detiene a configure) lo cual es necesario puesto que nuestro programa sencillamente no se puede usar si no se dispone de tal librería.

Nótese que las librerías se especifican sin el prefijo -l.

El archivo configure.ac actualmente luce así:

Siempre que se emplea AC_CHECK_HEADERS es recomendable que esté precedida de AC_PROC_CPP y AC_PROC_CC para evitar ciertos problemas sutiles que ocurren en situaciones más complicadas ^[15].

Dado que en mi sistema están disponibles tanto nanosleep() como también usleep(), tras ejecutar configure obtengo la siguiente información de config.h:

Es decir, solo una se reporta como disponible.

Tras repetir todo el proceso (desde aclocal…​), el nuevo ejecutable ejemplo1 contiene sólo una llamada a nanosleep() y ninguna a usleep():

Asimismo, puesto que mi sistema emplea la versión Ncurses (no Curses), los tests de selección de header y de librería generaron las definiciones correspondientes:

Como se puede apreciar en la última versión de nuestro ejemplo1.c, los tests relacionados a los archivos cabecera que se ubican en su parte inicial constituyen un número considerable de líneas (que pueden crecer con el tiempo.) Dado que esto se debe hacer para cada archivo de código fuente (*.c), es preferible especificarlo una única vez en un archivo cabecera general de la aplicación, el cual será incluido por todos los archivos de lenguaje C.

Esto por lo general ocurre en forma natural en las aplicaciones medianas y grandes, y lo haremos en este momento con fines didácticos. Nuestro archivo cabecera general se llamará ejemplo1.h y (por ahora) cuenta con el siguiente contenido:

Nótese que todo el contenido de este archivo cabecera se ha rodeado de directivas condicionales (relacionadas a EJEMPLO1_H) que se emplean para evitar su reprocesamiento en el caso de que el archivo fuera '#incluido' más de una vez; como de seguro ya sabe el lector, esto se debe hacer absolutamente con todo archivo cabecera se crea.

Gracias a éste, nuestro archivo de código fuente ejemplo1.c se reduce a:

Asimismo, automake requiere saber que el programa ahora depende también de un archivo cabecera. Así queda el nuevo Makefile.am:

Con motivo de soportar simultáneamente las funciones nanosleep() y usleep(), la función main() creció en diez líneas. Si nuestro programa requiriese a futuro invocar en otros puntos a nanosleep()/usleep(), el código se tornará rápidamente engorroso y difícil de readaptar a nuevos cambios.

A tal efecto es muy recomendable aislar este código no portable en una función aparte, y de preferencia en un archivo aparte. Por ejemplo, definiremos una nueva función llamada dormir() que reciba un entero long correspondiente a los "nanosegundos" que se pretende retardar ^[16]. Asimismo, crearemos el archivo domir.c con el siguiente contenido:

Agregaremos la declaración correspondiente al interior de ejemplo1.h:

Y gracias a esto, el ejemplo1.c se reduce a:

Y como era de esperarse, Makefile.am debe incluir la nueva fuente:

A partir de este momento, los programadores deben estar avisados de emplear exclusivamente "dormir()" en donde utilizarían nanosleep() o usleep().

Imaginemos que en un futuro lejano los nuevos estándares promueven una nueva manera de generar retardos (por ejemplo, una función llamada picosleep()), entonces nuestro programa sólo requeriría la modificación de la función dormir(); el resto permanecería incólume.

A modo de ejercicio para el lector se solicita adaptar este proyecto para que soporte ciertos sistemas derivados de Xenix (muy antiguos) que no cuentan ni con usleep() ni con nanosleep(), y por el contrario utilizan una llamada al sistema llamada nap(), la cual recibe un long que representa el retardo en milisegundos.

Si bien el archivo configure.ac es preprocesado por el macroprocesador M4, el resultado del mismo es ejecutado posteriormente por el shell. Esto significa que es posible introducir comandos de shell en este mismo archivo, teniendo cuidado de que no sean 'dañados' durante la etapa de M4.

A fin de ilustrar esto, corregiremos una sutil deficiencia de nuestro script configure: si lo ejecutamos en un sistema que no cuenta con ninguna clase de header Curses/Ncurses, el script lo descubre pero sigue avanzando como si no ocurriese nada malo. A continuación se muestra la ejecución de configure en un sistema con estas características; nótese que configure sólo se detiene al descubrir que no puede hallar una librería Curses/Ncurses para enlazar:

Téngase presente que hay sistemas que sí tienen la librería (y pasarían el último test del enlace), pero aun así no disponen de los headers que necesitamos, los cuales se suelen instalar como "software opcional de desarrollo". En ese caso, el usuario instalador recién descubriría el problema en el momento de compilar (gracias a la directiva #error que colocamos en ejemplo1.h):

Esto ocurre debido a que la macro AC_CHECK_HEADERS no tiene la capacidad de detener la ejecución del script cuando 'no se encuentra ninguno' de los headers especificados ^[17]. Sin embargo, con una pequeña modificación esto se puede conseguir:

Como indicamos, aquellas líneas de configure.ac que no corresponden a macros M4 serán pasadas 'casi' intactas al shell. En nuestro caso, hemos definido una variable de shell llamada curses-headers (el nombre es irrelevante) inicialmente igual a "no". Si la macro AC-CHECK-HEADERS encuentra al menos uno de los headers requeridos, entonces esta variable se modifica a "si" justo antes del "break". Posteriormente hacemos un test de shell (if...then...fi) y generamos un error en el caso de que la variable hubiera permanecido en "no" al haber fallado todos los casos de AC-CHECK-HEADERS.

Con esto, un sistema que carece de los headers (incluso si tiene las librerías) obtiene el siguiente mensaje durante configure:

Ya que hemos empezado a emplear el shell, es de rigor hacer un comentario con respecto a su portabilidad.

El script configure es la pieza clave en el descubrimiento y adaptación del software a las plataformas extrañas y sólo requiere de un shell estándar tipo Bourne para su ejecución. Sin embargo, históricamente los divesos sistemas Unix han tenido diversas divergencias en la implementación de su shell Bourne (/bin/sh.) Esto significa que el script configure debe ser construido con sumo cuidado a fin de utilizar sólo características probadamente portables entre todas las implementaciones del shell Bourne conocidas.

Como hemos visto, autoconf es la herramienta encargada de crear a configure, y está diseñada para utilizar estrictamente aquellas características del shell que son ampliamente portables. Sin embargo, en cualquier proyecto no trivial es menester que el desarrollador (nosotros) escriba algunas líneas complementarias utilizando el lenguaje del shell, tal como hicimos en la última versión de configure.ac. Como quiera que estas líneas serán introducidas en configure, debemos asegurarnos de que no dañen su portabilidad.

Esto significa que todo aquello que escribamos con el lenguaje del shell en el archivo configure.ac debe emplear una sintaxis ampliamente portable, lo cual no es tarea trivial.

Afortunadamente, los desarrolladores del GNU Build System ya han documentado con cierta amplitud este asunto, para lo cual remito al lector a consultar la documentación oficial de autoconf (sección "Portable Shell Programming".)

Asimismo, el hecho de que el script sea preprocesado por M4, obliga a evitar el uso de los caracteres que éste considera especiales, tales como los de "entrecomillado" ('[' y ']'.) Por tal motivo, en vez de utilizar

hemos optado por el comando equivalente "test".

El acceso a los sistemas de base de datos (DBMS) desde las aplicaciones constituye un requisito muy frecuente en la mayoría de ambientes comerciales. Existen muchas maneras de efectuar esto dependiendo de la plataforma, del lenguaje empleado, y de la base de datos instalada. En particular, nosotros intentaremos crear una aplicación en lenguaje C, independiente de la plataforma, y lo que es más importante, independiente del DBMS en uso.

Los creadores de productos DBMS normalmente proporcionan una interfaz de acceso (una librería) para el lenguaje C, y con frecuencia para otros lenguajes. Estas librerías son usadas por los programadores para conectarse e interactuar con la DBMS.

Lamentablemente esto "amarra" a los programas a una DBMS específica (pues cada una tiene su propia interfaz de programación o API), lo que hace que la migración a una nueva DBMS sea una tarea muy ardua. En otras palabras, los programas que hacen uso del API del creador de una base de datos, son poco portables a otras bases de datos.

Debido a esto, existen diversas librerías que "aislan" a las aplicaciones de las API’s específicas de cada DBMS, incrementando su portabilidad.

En esta sección, a modo de ejercicio, desarrollaremos una pequeña y muy incompleta librería para acceder a distintas bases de datos SQL, así como un programa (también muy pequeño) que hace uso de la misma, consiguiendo en efecto ser totalmente portable a cualquier base de datos ^[18]. Nuestra librería será denominada "SAL" (SQL Abstraction Layer.)

Asumiremos también que nuestra aplicación consta de un número significativo de archivos (cosa que no es cierta) por lo que crearemos una estructura de directorios más acorde un un paquete grande.

Por último, nuestro paquete proporcionará algunos archivos de documentación técnica, cuyo contenido aquí no es relevante.

A partir de un nuevo directorio en blanco, crearemos la siguiente estructura:

Téngase presente que el GNU Build System NO obliga a ninguna estructura de directorios en particular; sin embargo, existen diversas "costumbres" que es conveniente tener en consideración a fin de no desconcertar a los usuarios de nuestro paquete.

El directorio doc/ contendrá la documentación técnica del paquete. Sin embargo, de las secciones anteriores sabemos que automake crea automáticamente ciertos archivos de texto (y obliga a crear otros.) Todos estos archivos corresponden a información general y legal acerca del paquete, pero no corresponden a la documentación técnica. Los archivos informativos/legales siempre deben permanecer en el directorio inicial (o raíz) del paquete, que es desde donde se ejecuta automake, en tanto que la documentación técnica se suele almacenar en su propio directorio.

Todo el código fuente ahora se ubicará bajo src/, el cual a su vez contendrá los subdirectorios: lib/ para contener el código fuente de las librerías generadas con nuestro paquete, y exe/ para contener el código fuente de los ejecutables que genera nuestro paquete.

La directiva AC_PROG_RANLIB debe agregarse a configure.ac siempre que el proyecto va a generar alguna librería (como es nuestro caso ^[19].) En segundo lugar, cada vez que se crean estructuras de directorios en los que el software será construído, es conveniente emplear la directiva AC_PROG_MAKE_SET a fin de resolver ciertos problemas inherentes a ciertas versiones extrañas de make. Asimismo, en AC_CONFIG_FILES es menester especificar 'todos' los Makefiles que se van a generar. Estos Makefiles se invocarán recursivamente cuando el usuario instalador ejecute make desde el directorio principal.

Por último, 'la experiencia' indica que los archivos cabecera de MySQL pueden ubicarse en la ruta estándar o bajo su propio subdirectorio, por lo que usamos AC_CHECK_HEADERS (análogo a lo que se hizo anteriormente para Curses/Ncurses); igualmente, verificamos la disponibilidad de la librería de MySQL probando la "enlazabilidad" de la función (elegida al azar en el API) mysql_real_connect() mediante nuestra conocida AC_SEARCH_LIBS.

Finalmente, recordemos que sólo es necesario un único archivo configure.ac para todo el proyecto, el cual siempre estará ubicado en el directorio principal del mismo.

El archivo cabecera (sal.h) se ubica en src/lib/:

En las últimas líneas de este archivo se encuentran las cuatro funciones de que consta nuestra librería las cuales se emplean, respectivamente, para conectar con la DBMS, ejecutar un 'query', liberar la memoria asociada a un "cursor/result set", e iterar obteniendo filas a través de un "cursor/result set".

Quizá el lector tenga curiosidad por comprender los tipos de datos declarados en este archivo (aunque no afectan a nuestra exposición):

El tipo SQL_ROW corresponde a una fila retornada por la base de datos. Asumiremos que estas filas están siempre constituidas de arreglos de cadenas de caracteres "char *". De este modo, si más adelante se definiera:

Los campos retornados se podrían apreciar mediante:

La estructura SQL_RSET_STRUCT se emplea como "contenedora" de un "result set" (el resultado de un query.) Dependiendo de la DBMS y las opciones empleadas, esto a veces corresponde a un área de memoria con toda la información generada por la consulta, o en otras ocasiones, a un "cursor" que sirve para traer fila a fila la información desde el servidor.

Con el fin de hacerla más general, nuestra librería asume que el "result set" tiene el comportamiento de un "cursor" y proporciona funciones para iterar sobre el mismo. En las bases de datos que retornan toda la información en un solo paso, nuestro "result set" simula un comportamiento de "cursor" entregando fila a fila la información a la aplicación ^[20].

En cualquier caso, el "cursor" o "result set" 'real' que devuelve la DBMS, se referencia internamente mediante el puntero resultSet que tiene tipo "desconocido" void* puesto que la interfaz debe de ser independiente de la DBMS en uso.

El código que se presenta a continuación (sal.c) implementa la interfaz de programación definida en sal.h. En esta primera versión el código fuente está asociado a la DBMS MySQL:

La explicación de este archivo involucaría explicar el API de la librería de clientes de MySQL, cosa que está más allá de mi objetivo. El lector interesado puede consultar fácilmente la documentación respectiva en el .URL http://www.mysql.com/ Sitio Web de MySQL .

El único aspecto a tener claro aquí es que el código de este archivo es completamente específico para la base de datos MySQL y requiere una reescritura completa para acceder a otras bases de datos.

Este programa de ejemplo emplea la librería libsal y es totalmente independiente de la base de datos utilizada:

Nuestro programa consola.c tiene por finalidad recibir un texto del usuario desde la consola, el cual se asume como una sentencia SQL a ser lanzada al DBMS. A continuación el programa recoge todas las filas resultantes y muestra en la pantalla tan sólo la primera columna de cada una de éstas ^[21]. Para esto, invoca a SQL-query() con el texto proporcionado, obteniendo un "result set" en la variable 'r'. Con este "result set" a modo de cursor, se trae todas las filas una a una (con SQL-fetch-row()) en la variable f. Finalmente, sólo imprimiremos el primer campo "f[0]".

La escritura de documentación técnica de un proyecto de software está más allá del alcance del presente texto, sin embargo, haré algunos comentarios con respecto a las alternativas disponibles:

Esta es la parte más novedosa del proyecto. Tenemos que recordar que 'para cada directorio' donde se generará un Makefile (y que fueron especificados en configure.ac), debemos escribir un nuevo Makefile.am. Asimismo, automake sólo se debe ejecutar desde el directorio principal, nunca desde otro.

Veamos esto caso por caso:

Teniendo todo esto listo, generamos los archivos de construcción desde el directorio principal del proyecto (no hay necesidad de descender a ningún otro):

Como se comentó, siempre es preferible (mas no imprescindible) "configurar" y "construir" desde otro directorio totalmente ajeno al de nuestras fuentes:

El lector comprederá que este no es el lugar adecuado para explicar cómo instalar MySQL y configurar una base de datos (lo cual para esta DBMS es increíblemente sencillo.) Asumiremos por tanto que se dispone de una base de datos llamada "testsal", accesible vía "localhost" con el usuario "diego" y el password "password". El ejemplo que se muestra a continuación asume también la existencia de una tabla llamada 'tabla1':

El usuario instalador de nuestro paquete deberá elegir qué tipo de base de datos emplear, lo cual ocasionará que la librería libsal compile diferente código fuente.

A fin de que el usuario instalador especifique este tipo de opciones, el script configure proporciona un mecanismo estándar mediante las opciones --enable-FEATURE y --disable-FEATURE, las cuales sirven, respectivamente, para activar y desactivar ciertas opciones en el paquete que se va a compilar.

En nuestro caso, 'obligaremos' a que el usuario instalador especifique una de las opciones --enable-mysql o --enable-postgresql para indicar con qué clase de base de datos se conectará la librería libsal. Para tal fin, presentamos una nueva versión de configure.ac que hace uso de la macro AC_ARG_ENABLE. Esta macro debe ser empleada con cada "opción" o "FEATURE" que el usuario puede especificar a configure. Su primer argumento corresponde al texto de la "opción" (que debe ser una palabra simple), seguida de un texto de ayuda el cual aparece cuando el usuario instalador utiliza la opción --help de configure.

Es recomendable (pero no obligatorio) crear este texto de ayuda mediante la macro AC_HELP_STRING, la cual recibe a su vez dos argumentos correspondientes a dos textos que aparecerán adecuadamente formateados para la salida de configure --help: el primero debería contener la opción tal como el usuario instalador debe escribirla, y el segundo, una explicación de la misma.

El tercer argumento (opcional) de AC_ARG_ENABLE corresponde una acción a ser ejecutada cuando el usuario selecciona la opción o FEATURE. En nuestro caso, hemos invocado a AC_DEFINE a fin de definir una nueva macro a ser incluida en config.h, la cual permite seleccionar el código correspondiente a cada base de datos que debe ser compilado (ver código fuente en sal.c.)

Asimismo, para cada opción o "FEATURE" que el usuario seleccione al ejecutar configure, AC_ARG_ENABLE definirá una variable de shell de nombre "enable+FEATURE" con valor 'yes', la cual se emplea más adelante para determinar qué funcionalidad debe analizarse en la plataforma. Para nuestro caso, las variables correspondientes serán enable_mysql y enable_postgresql; y mediante comandos de Shell obligaremos al usuario instalador a definir exactamente una de ellas, es decir, a seleccionar exactamente una base de datos.

A continuación la nueva versión de configure.ac:

En esta nueva versión el código fuente de sal.c contiene código condicional tanto para MySQL como para PostgreSQL (nótese que sal.h no se altera):

Nuevamente, entender el detalle de éste código involucra conocer el API de ambas bases de datos, cosa que está fuera de nuestros objetivos.

A continuación preparamos el script configure y lo ejecutamos (erróneamente) sin argumentos:

Especifiquemos esta vez la base de datos PostgreSQL:

Tras preparar un ambiente PostgreSQL idéntico al que se utilizó en MySQL, obtenemos:

En rigor, el programa se debería utilizar sólo después de haberse instalado en forma definitiva:

Tal como se aprecia, los únicos archivos que se han instalado son /usr/local/bin/consola y /usr/local/lib/libsal.a; es decir, sólo se han instalado aquellos "objetivos" que se espeficó construir.

A modo de ejercicio para esta sección, se deja al lector investigar y corregir por qué lo siguiente…​

…​genera definiciones incorrectas en config.h:

Asumiendo que Ud. ya conoce el concepto y la utilidad de las librerías compartidas (sino, vea el apéndice C), es menester indicar ahora algunos inconvenientes que acarrea su utilización:

A fin de contrarrestar estos problemas, el GNU Build System proporciona la herramienta libtool, la cual se suele utilizar en conjunto con las anteriormente explicadas; de hecho, nosotros no la invocaremos directamente, sino que será automáticamente utilizada como parte del proceso normal de construcción ^[26].

Normalmente, libtool intentará utilizar librerías compartidas para todas las solicitudes de compilación y enlace; pero si la plataforma no soporta aquellas, (o el usuario lo requiere expresamente), empleará la versión estática.

Al emplearse libtool es necesario agregar la macro AC_PROG_LIBTOOL. Asimismo, AC_PROG_RANLIB se torna redundante:

Aquí especificaremos la construcción de la librería utilizando libtool. Como se aprecia, las librerías creadas con Libtool se especifican con lib_LTLIBRARIES y tienen una pseudo-extensión "la". Para cada librería, como es de rigor, se deben especificar sus fuentes y finalmente, dado que pretendemos crear librerías compartidas debemos especificar la "versión" de la librería (que NO es igual a la de nuestro paquete) mediante LDFLAGS empleando la directiva de Libtool "-version-info" ^[27].

Asimismo, puesto que hemos decidido facilitar a otros desarrolladores el acceso a nuestra librería, se hace necesario instalar en un lugar público el archivo cabecera sal.h. Con este fin hemos agregado la directiva include_HEADERS que especifica qué archivos cabecera (del directorio actual) se deberán instalar (al ejecutar make install.) Como indicamos, los archivos cabecera se instalan por omisión en /usr/local/incude.

Como es usual, ejecutamos la secuencia aclocal ; autoheader ; automake ; autoconf y a continuación (de preferencia desde un nuevo directorio), el script configure eligiendo cualquiera de las bases de datos como se hizo anteriormente. Finalmente, se ejecuta make.

Veamos los archivos generados en lib/:

Como se aprecia, libtool genera la "librería" con extensión ".la" así como los archivos "objeto" sal.o y sal.lo, el último de los cuales corresponde a una versión de sal.o compilada con la opción de "código independiente de la posición" usada especialmente para librerías compartidas. Si se revisa el archivo libsal.la, se comprobará que en realidad se trata de un archivo de texto con información relevante para libtool, el cual hace referencia a los verdaderos archivos de librería que están bajo el directorio oculto .libs. En este último se aprecia que libtool ha generado tanto la versión estática (libsal.a) como la dinámica de libsal (libsal.so.0.0.0):

La intención es que todo esto permanezca oculto y que el desarrollador sólo tome en cuenta a "libsal.la".

Pasemos ahora a verificar el ejecutable:

Todo luce normal. Sin embargo:

Nuevamente, libtool está "ocultando" al verdadero ejecutable (que esta vez está bajo src/exe/.libs):

El lector observador habrá descubierto que el verdadero ejecutable no puede en realidad funcionar:

El motivo es evidentemente que el ejecutable requiere enlazar con libsal.so.0 (vea la salida de ldd más arriba) y ésta no puede ser hallada debido a que no se encuentra en ningún directorio estándar, ni se ha especificado su ubicación. Precisamente esto es lo que resuelve el script "ficticio" src/exe/consola, creado por libtool.

Pasemos a la instalación:

Como de costumbre, las librerías se instalan por omisión en /usr/local/lib y el ejecutable se instala como /usr/local/bin/consola; nótese que ya no se crean directorios ocultos auxiliares como ocurría en el "directorio de construcción". Si ahora ejecutamos el programa, obtenemos el mismo error que explicamos más arriba.

Téngase en cuenta que este problema no tiene ninguna relación con Libtool, sino exclusivamente con la configuración de las rutas de las librerías compartidas.

Este problema se puede corregir de diversas maneras. En muchas plataformas, la más sencilla consiste en emplear la variable de entorno LD_LIBRARY_PATH, que instruye al enlazador de tiempo de ejecución a buscar las librerías en rutas adicionales:

Una segunda solución consiste en instalar la librería en un directorio estándar de librerías del sistema operativo, para lo cual sólo se requiere repetir el proceso agregando lo siguiente:

Este comando asume que el directorio /usr/lib es uno de los directorios estándares de librerías compartidas.

Una tercera solución corresponde a agregar nuestro directorio problemático /usr/local/lib a la lista de librerías de búsqueda del sistema operativo ^[28]; sin embargo, esta solución me parece demasiado intrusiva y muy poco portable.

Una última solución que presentamos consiste en generar un ejecutable preparado para buscar siempre en /usr/local/lib aquellas librerías que le faltan. Esto se consigue con diversas opciones del enlazador que varían en distintas plataformas; sin embargo, libtool, nos proporciona una sintaxis estándar para lo cual sólo tendremos que modificar el archivo src/exe/Makefile.am agregando la opción -rpath en las opciones de enlace:

El "Makefile" anteriormente presentado puede guardarse en cualquier archivo de texto, aunque por comodidad se suele utilizar el nombre "Makefile" o "makefile".

Pruebe a compilar el programa a partir de los módulos. Empiece borrando el ejecutable y los módulos objeto para ver el proceso completo:

Ahora invoque a "make". A continuación muestro lo que obtuve en mi computador ^[30]:

Si volvemos a invocar a make Ud. apreciará que éste se niega a hacer algo debido a que todo está ahora actualizado.

Supogamos ahora que modificamos a modulo1.c. Podríamos hacer un cambio editando el archivo, pero para engañar a make simplemente basta con que actualicemos su fecha de modificación (a fin de que sea más reciente que los archivos que dependen de éste.) El comando touch puede actualizar esa fecha:

Observe con atención que make sólo ha compilado lo necesario (no ha recompilado modulo2.c.) Cómo logra hacerlo es lo que veremos a continuación.

Hace un momento presenté una 'probable' regla implícita para construir un archivo objeto (.o) a partir de un archivo fuente C (.c). A continuación presento una versión más acorde con la realidad:

Esto quiere decir que es posible usar un compilador distinto a gcc con facilidad (al menos desde el punto de vista de make) simplemente definiendo la variable CC al inicio del Makefile. Asimismo, la variable CFLAGS permite introducir algunas opciones al proceso de compilación (ver más adelante.)

Make es un programa tremendamente sofisticado. Aquí sólo hemos presentado los aspectos más elementales, aunque ya estamos en capacidad de compilar proyectos pequeños. En Linux la versión de Make distribuida es GNU Make, la cual presenta numerosas extensiones y algunas incopatibilidades con respecto a las versiones "oficiales" de los Unix’es. Para más información sobre GNU Make, consúltese la documentación "info" (info make.)

Aunque la librería estándar ya proporciona un conjunto de funciones para procesamiento de cadenas de caracteres (strcpy, strcat, strchr, etc.) es recurrente la necesidad de diversas funciones adicionales tales como:

A esta pequeña librería le denominaremos "stringplus".

A fin de hacer la explicación más interesante y general, implementaremos cada función en un archivo aparte:

Ahora crearemos un pequeño programa para probar todo el código anterior (prueba.c):

Las librerías estáticas consisten simplemente en empaquetar los archivos de código objeto (*.o) en un solo gran archivo (con extensión "*.a") usando el clásico comando "ar" ^[33]. Este archivo se puede enlazar con el compilador como si fuese cualquier otro archivo objeto.

Dados los archivos del ejemplo anterior, el siguiente Makefile genera el archivo de librería estática "stringplus.a", y lo enlaza con el código de prueba (prueba.c):

La ejecución de make se muestra a continuación ^[34]:

Con esto, la distribución de la librería se limita a los archivos:

A esta clase de librería se le conoce como "librería estática". Los ejecutables enlazados con librerías estáticas pueden ser llevados a otros computadores (de la misma plataforma) sin necesidad de llevar también la librería, pues ésta ya está contenida en aquellos.

El esquema de enlace con librerías estáticas funciona bien, pero tiene algunas características que pueden ser muy indeseables:

Las librerías compartidas (conocidas como shared libraries o dynamic libraries) resuelven todos estos problemas de un modo bastante completo, a costa de cierta complejidad añadida.

Lamentablemente el procedimiento necesario para hacer esto no es totalmente estandarizado entre Unix’es, y lo que haremos aquí (Linux/gcc) puede requerir adaptaciones para otros ambientes.

El siguiente Makefile permite obtener la librería "libstringplus.so" y enlazarla con "prueba.c":

Convencionalmente, las librerías dinámicas tienen un nombre de archivo de la forma "libXXX.so.v.m.r" ^[35], donde la extensión "*.so" indica que se trata de un "shared object"; "v", "m" y "r" son enteros positivos: "v" corresponde a la "versión" de la librería, "m" es el "número menor", y "r" el "release". Diferentes valores para el número "v" significan diversas versiones *incompatibles* de la librería ^[36]; por el contrario, distintos valores de "m" corresponden a versiones compatibles de la misma ^[37], y finalmente "r" (que es opcional) complementa a "m" permitiendo indicarle mayor granularidad. En conjunto, estos números permiten la coexistencia de distintas versiones de una librería.

Por simplicidad, en lo que sigue no emplearemos los números "v", "m" y "r", aunque cumplen una función fundamental para el correcto manejo de "dependencias" de las aplicaciones, por lo que se recomienda leer el .URL http://www.dwheeler.com/program-library Programming Library HOWTO .

Usando gcc, la opción -shared genera librerías compartidas mientras que la opción -fpic ^[38] genera código máquina con "direcciones independientes de la posición", lo cual es indicado para todos los módulos constituyentes de las librerías compartidas (mas no es necesario para los programas que las invocan. ^[39])

Ahora bien, esta "shared library" por definición NO está contenida en el archivo ejecutable con quien está enlazada. Por ejemplo, nuestro ejecutable (prueba) sólo contiene una 'referencia' a "libstringplus.so" ^[40], la que deberá ser cargada a memoria recién en el momento de la ejecución del programa.

Esto significa que si queremos llevar nuestro ejecutable "prueba" a otro computador, también tendremos que llevar por separado "libstringplus.so".

Para apreciar a qué shared library’s hace referencia nuestro ejecutable prueba, podemos usar el comando ldd:

Como se aprecia, nuestra librería está referenciada aunque no está siendo encontrada (ver mensaje "not found".) Esto se debe a que las shared library’s tienen que colocarse en ciertos directorios especiales en el sistema previamente a su uso.

Si tratamos de ejecutar el programa, éste fallará:

Una manera 'temporal' de solucionar esto consiste en especificar la variable de entorno "LD_LIBRARY_PATH" con el directorio en el que se encuentra "libstringplus.so". En nuestro caso, es el directorio actual ("."):

A continuación tres implementaciones que nos permiten obtener el factorial de un número entero (retornando un entero largo.)

Como se aprecia, nuestro programa central accede a las "shared libraries" mediante la función dlopen(). Ésta retorna un puntero tipo (void *) que sirve para hacer referencia al contenido de la misma (o NULL en caso de error.) Obsérve que requiere especificar la ruta completa (en este caso con "./") pues en caso contrario buscará la librería sólo en los lugares preconfigurados del sistema (ver discusión sobre esto más arriba en la sección de creación de shared libraries ^[47].) Pruebe a usar "fact1.so" en lugar de "./fact1.so" para que lo compruebe.

Teniéndose el "handler" a la shared library, es posible obtener un puntero a cualquier objeto de la misma (una función o una variable.) Para esto se emplea la función dlsym() que recibe como argumento el nombre de este objeto (lo que en las librerías se conoce como un símbolo.) Estos punteros deben ser del tipo adecuado al objeto al que se está referenciando (en nuestro caso, un puntero a función que recibe "int" y retorna "long".)

Cuando el programa ya no requiere acceder a estos objetos, el "handler" obtenido con dlopen() debe cerrarse con dlclose() (nuestro programa de prueba finaliza de inmediato, por lo que no vale la pena la molestia.)

A continuación proporcionamos los archivos constituyentes de dos librerías triviales, y un programa que hace uso de éstas. Esto nos permitirá mostrar un error que aparece con relativa frecuencia, generado por referencias no resueltas:

En el ejemplo que mostramos a continuación el programa principal (prueba.c) invoca mediante dlopen() a la librería "checksum" que contiene la función del mismo nombre. Esta función requiere tener acceso al string llamado "compartido", el cual está definido en el programa prueba.c: