Réponses:
Il s'agit d'un fichier texte qui comprend une description de la bibliothèque.
Il permet libtool
de créer des noms indépendants de la plateforme.
Par exemple, libfoo
va à:
Sous Linux:
/lib/libfoo.so # Symlink to shared object
/lib/libfoo.so.1 # Symlink to shared object
/lib/libfoo.so.1.0.1 # Shared object
/lib/libfoo.a # Static library
/lib/libfoo.la # 'libtool' library
Sous Cygwin :
/lib/libfoo.dll.a # Import library
/lib/libfoo.a # Static library
/lib/libfoo.la # libtool library
/bin/cygfoo_1.dll # DLL
Sous Windows MinGW:
/lib/libfoo.dll.a # Import library
/lib/libfoo.a # Static library
/lib/libfoo.la # 'libtool' library
/bin/foo_1.dll # DLL
C'est donc libfoo.la
le seul fichier qui est conservé entre les plateformes en libtool
permettant de comprendre ce qui se passe avec:
Sans dépendre d'une plateforme d'implémentation spécifique des bibliothèques.
libtool
pour lier les fichiers objets ( gnu.org/software/libtool/manual/html_node/Using-Automake.html ) mais si je veux distribuer une bibliothèque sans .la, cela signifie-t-il qu'il sera très difficile de lier avec lui en utilisant Cygwin ou mingw?
Selon http://blog.flameeyes.eu/2008/04/14/what-about-those-la-files , ils sont nécessaires pour gérer les dépendances. Mais utiliser pkg-config peut être une meilleure option:
Dans un monde parfait, chaque bibliothèque statique nécessitant des dépendances aurait son propre fichier .pc pour pkg-config, et chaque paquet essayant de se lier statiquement à cette bibliothèque utiliserait pkg-config --static pour obtenir le lien vers les bibliothèques.
J'ai trouvé de très bonnes explications sur les fichiers .la ici http://openbooks.sourceforge.net/books/wga/dealing-with-libraries.html
Résumé (La façon dont j'ai compris): Parce que libtool traite les bibliothèques statiques et dynamiques en interne (via --diable-shared ou --disable-static), il crée un wrapper sur les fichiers de bibliothèque qu'il construit. Ils sont traités comme des fichiers de bibliothèque binaires dans l'environnement pris en charge par libtool.