Es ist eine Textdatei, die eine Beschreibung der Bibliothek enthält.
Es erlaubt libtool
um plattformunabhängige Namen zu erstellen.
Beispiel:libfoo
geht zu:
Unter 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
Unter Cygwin:
/lib/libfoo.dll.a # Import library
/lib/libfoo.a # Static library
/lib/libfoo.la # libtool library
/bin/cygfoo_1.dll # DLL
Unter Windows MinGW:
/lib/libfoo.dll.a # Import library
/lib/libfoo.a # Static library
/lib/libfoo.la # 'libtool' library
/bin/foo_1.dll # DLL
Also libfoo.la
ist die einzige Datei, die von libtool
zwischen den Plattformen aufbewahrt wird ermöglicht zu verstehen, was passiert mit:
- Bibliotheksabhängigkeiten
- Tatsächliche Dateinamen
- Bibliotheksversion und -revision
Ohne Abhängigkeit von einer bestimmten Plattformimplementierung von Bibliotheken.
Laut http://blog.flameeyes.eu/2008/04/14/what-about-those-la-files werden sie benötigt, um mit Abhängigkeiten umzugehen. Aber die Verwendung von pkg-config könnte eine bessere Option sein:
In einer perfekten Welt hätte jede statische Bibliothek, die Abhängigkeiten benötigt, ihre eigene .pc-Datei für pkg-config, und jedes Paket, das versucht, statisch mit dieser Bibliothek zu verknüpfen, würde pkg-config --static verwenden, um die Bibliotheken zum Verknüpfen zu erhalten.
Ich habe hier http://openbooks.sourceforge.net/books/wga/dealing-with-libraries.html
eine sehr gute Erklärung zu .la-Dateien gefundenZusammenfassung (wie ich es verstanden habe):Da libtool intern mit statischen und dynamischen Bibliotheken umgeht (durch --diable-shared oder --disable-static), erstellt es einen Wrapper für die Bibliotheksdateien, die es erstellt. Sie werden als binäre Bibliotheksdateien in einer von libtool unterstützten Umgebung behandelt.