Respostas:
É um arquivo de texto que inclui uma descrição da biblioteca.
Permite libtool
criar nomes independentes de plataforma.
Por exemplo, libfoo
vai para:
No 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
Sob Cygwin :
/lib/libfoo.dll.a # Import library
/lib/libfoo.a # Static library
/lib/libfoo.la # libtool library
/bin/cygfoo_1.dll # DLL
No Windows MinGW:
/lib/libfoo.dll.a # Import library
/lib/libfoo.a # Static library
/lib/libfoo.la # 'libtool' library
/bin/foo_1.dll # DLL
Assim libfoo.la
é o único arquivo que é preservado entre plataformas, libtool
permitindo entender o que acontece com:
Sem depender de uma plataforma específica de implementação de bibliotecas.
libtool
para vincular os arquivos de objeto ( gnu.org/software/libtool/manual/html_node/Using-Automake.html ), mas se eu quiser distribuir uma biblioteca sem .la, isso significa que será muito difícil vincular com ele usando Cygwin ou mingw?
De acordo com http://blog.flameeyes.eu/2008/04/14/what-about-those-la-files , eles são necessários para lidar com dependências. Mas usar o pkg-config pode ser uma opção melhor:
Em um mundo perfeito, toda biblioteca estática que precisa de dependências teria seu próprio arquivo .pc para o pkg-config, e todo pacote que tentasse se conectar estaticamente a essa biblioteca usaria o pkg-config --static para obter as bibliotecas às quais se vincular.
Encontrei uma explicação muito boa sobre arquivos .la aqui http://openbooks.sourceforge.net/books/wga/dealing-with-libraries.html
Resumo (da maneira que eu entendi): Como a libtool lida com bibliotecas estáticas e dinâmicas internamente (por meio de - compartilhamento confiável ou - estática desativável), ele cria um wrapper nos arquivos de biblioteca que constrói. Eles são tratados como arquivos de biblioteca binária no ambiente suportado pela libtool.