Il s'agit d'un fichier texte qui inclut une description de la bibliothèque.
Il permet libtool pour créer des noms indépendants de la plate-forme.
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
Alors libfoo.la est le seul fichier conservé entre les plates-formes par libtool permettant de comprendre ce qui se passe avec :
- Dépendances de la bibliothèque
- Noms de fichiers réels
- Version et révision de la bibliothèque
Sans dépendre d'une plate-forme spécifique d'implémentation de bibliothèques.
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 que les bibliothèques soient liées.
J'ai trouvé une très bonne explication sur les fichiers .la icihttp://openbooks.sourceforge.net/books/wga/dealing-with-libraries.html
Résumé (d'après ce que j'ai compris) :étant donné 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 avec un environnement pris en charge par libtool.