Si me bajo una librería de C++ >> ¿cómo debo usarla desde mi aplicación C++? Me imagino que la idea no es ponerse a desarrollar dentro de los fuentes de la librería y hackear los Makefile pa que compilen mis nuevos ejecutables como lo estoy haciendo. Además los Makefile usan rutas relativas (../) a la librería, entonces al debuggear obviamente no compila para el IDE.
En Java me bajaría un .jar y lo incluiría en el build path, en el mundo C++ el equivalente serían los .dll. Pero éstas son librerías dinámicas, ¿es ésto necesario?, también existen las librerías estáticas y las librerías compartidas.
- Las librerías estáticas>> son linkeadas en tiempo de compilación y se convierten en un archivo de objeto y un ejecutable. Son las (.a en unix o .lib en wintendo) ¿No me queda claro si ésto (static build) es exportándolo hacia otra aplicación? Dice que ésto se puede mezclar con otras librerías para generar un sólo ejecutable (lo cual me serviría) o se puede incluír dentro de otra librería (mejor).
- Las librerías compartidas >> son linkeadas en tiempo de ejecución, aunque el compilador puede verificar que se encuentren las dependencias. Éstas son las que se usan en el linkeo dinámico (.dll o .dso en unix)
La ventaja de las primeras es que sabemos al compilar si están todos los requerimientos, que no hay problemas de dependencias, que sólo se cargan las librerías necesarias y que el resultado es un sólo ejecutable. De las segundas, el diseño modular es mucho más mantenible (se puede arreglar un bug de una librería que muchos programas usan, por ej.) y los programas resultantes son mucho más livianos.
Como ésta es una app para distribuír, lo que nos serviría sería una librería estática. Entonces, ¿cómo se hace? Veamos >>
De la introducción, aparte de aclarar que tanto las librerías estáticas como compartidas pueden ser cargadas dinámicamente, me llama la atención que se menciona libtool como una interfaz para simplificar la complejidad de las librerías compartidas. El problema es que la librería que quiero importar usa libtool, ¿será que estoy obligado a importarla como compartida?
Ok, entonces con el comando ar puedo crear librerías estáticas, y pasarle nuevos objetos (.o) una vez que ya existe. Para usarla, dice que al compilar con gcc, se le pasa -l con las librerías que quiero incluír. ¿Ésto no puede hacerse a nivel del código?
Mmm entiendo, las librerías dinámicas se instalan en el S.O. (justamente para que otros programas las usen), y en el caso de sistemas GNU, el comando make los deja en /usr/local/lib. Luego, ¿Cómo se usan?
Me había asustado pensando que los famosos
#include<...>
de C++eran los dynamic loading, pero no.
De hecho junto con los .so tengo un .a
así es que vamos a dejar la teoría hasta acá y veamos cómo hacer el enlace.
Ésto ya es una avance. Estaba intentando incluir el .a como –include (Compiler > Include) pero en realidad lo que necesito no es un comando para el compilador sino que para el linker. En Eclipse CDT ésto se hace en Properties > Settings > C/C++ build > Settings > Tool Settings > GCC C++ Linker > Libraries (-l) al que hay que pasarle el nombre de la librería sin el lib ni el .a.
