Risposte:
È un file testuale che include una descrizione della libreria.
Permette libtool
di creare nomi indipendenti dalla piattaforma.
Ad esempio, libfoo
va a:
Sotto 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
Sotto Cygwin :
/lib/libfoo.dll.a # Import library
/lib/libfoo.a # Static library
/lib/libfoo.la # libtool library
/bin/cygfoo_1.dll # DLL
In Windows MinGW:
/lib/libfoo.dll.a # Import library
/lib/libfoo.a # Static library
/lib/libfoo.la # 'libtool' library
/bin/foo_1.dll # DLL
Quindi libfoo.la
è l'unico file che viene conservato tra le piattaforme libtool
consentendo di capire cosa succede con:
Senza dipendere da una specifica piattaforma di implementazione delle librerie.
libtool
collegamento dei file oggetto ( gnu.org/software/libtool/manual/html_node/Using-Automake.html ) ma se voglio distribuire una libreria senza .la, significa che sarà molto difficile collegarsi con esso usando Cygwin o mingw?
Secondo http://blog.flameeyes.eu/2008/04/14/what-about-those-la-files , sono necessari per gestire le dipendenze. Ma usare pkg-config potrebbe essere un'opzione migliore:
In un mondo perfetto, ogni libreria statica che necessita di dipendenze avrebbe il proprio file .pc per pkg-config, e ogni pacchetto che tenta di collegarsi staticamente a quella libreria userebbe pkg-config --static per ottenere il collegamento delle librerie.
Ho trovato un'ottima spiegazione sui file .la qui http://openbooks.sourceforge.net/books/wga/dealing-with-libraries.html
Riepilogo (Il modo in cui ho capito): Poiché libtool si occupa internamente di librerie statiche e dinamiche (tramite --diable-shared o --disable-static) crea un wrapper sui file di libreria che crea. Sono trattati come file di libreria binaria con ambiente supportato in libtool.