Odpowiedzi:
Jest to plik tekstowy zawierający opis biblioteki.
Pozwala libtool
na tworzenie nazw niezależnych od platformy.
Na przykład libfoo
idzie do:
W systemie 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
Pod Cygwinem :
/lib/libfoo.dll.a # Import library
/lib/libfoo.a # Static library
/lib/libfoo.la # libtool library
/bin/cygfoo_1.dll # DLL
W systemie Windows MinGW:
/lib/libfoo.dll.a # Import library
/lib/libfoo.a # Static library
/lib/libfoo.la # 'libtool' library
/bin/foo_1.dll # DLL
libfoo.la
Jest to więc jedyny plik zachowywany między platformami, libtool
umożliwiając zrozumienie, co się dzieje z:
Bez uzależnienia od konkretnej platformy implementacji bibliotek.
libtool
linkowaniu plików obiektowych ( gnu.org/software/libtool/manual/html_node/Using-Automake.html ), ale jeśli chcę dystrybuować bibliotekę bez .la, oznacza to, że będzie to bardzo trudne za pomocą Cygwin lub mingw?
Według http://blog.flameeyes.eu/2008/04/14/what-about-those-la-files są one potrzebne do obsługi zależności. Ale użycie pkg-config może być lepszą opcją:
W idealnym świecie każda statyczna biblioteka wymagająca zależności miałaby swój własny plik .pc dla pkg-config, a każdy pakiet próbujący statycznie połączyć się z tą biblioteką używałby pkg-config --static, aby pobrać biblioteki do połączenia.
Znalazłem bardzo dobre wyjaśnienie dotyczące plików .la tutaj http://openbooks.sourceforge.net/books/wga/dealing-with-libraries.html
Podsumowanie (tak jak zrozumiałem): Ponieważ libtool zajmuje się wewnętrznie bibliotekami statycznymi i dynamicznymi (poprzez --diable-shared lub --disable-static), tworzy opakowanie na tworzonych plikach bibliotek. Są one traktowane jako binarne pliki bibliotek w środowisku obsługiwanym przez libtool.