Відповіді:
Це текстовий файл, який включає опис бібліотеки.
Це дозволяє libtool
створювати незалежні від платформи імена.
Наприклад, libfoo
переходить до:
Під 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
Під Cygwin :
/lib/libfoo.dll.a # Import library
/lib/libfoo.a # Static library
/lib/libfoo.la # libtool library
/bin/cygfoo_1.dll # DLL
Під 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
це єдиний файл, який зберігається між платформами, libtool
дозволяючи зрозуміти, що відбувається з:
Без залежності від конкретної платформи реалізації бібліотек.
libtool
посилання об’єктних файлів ( gnu.org/software/libtool/manual/html_node/Using-Automake.html ), але якщо я хочу розповсюдити бібліотеку без. з ним за допомогою Cygwin або mingw?
Згідно з http://blog.flameeyes.eu/2008/04/14/what-about-those-la-files , вони потрібні для вирішення залежностей. Але використання pkg-config може бути кращим варіантом:
У ідеальному світі кожна статична бібліотека, яка потребує залежностей, матиме свій власний .pc файл для pkg-config, і кожен пакет, який намагається статично зв’язатися з цією бібліотекою, використовує pkg-config --static, щоб змусити бібліотеки посилатися.
Тут я знайшов дуже гарне пояснення щодо файлів .la http://openbooks.sourceforge.net/books/wga/dealing-with-libraries.html
Короткий зміст (наскільки я зрозумів): Оскільки libtool працює з статичними та динамічними бібліотеками всередині (через --diable-shared або --disable-static), він створює обгортку для бібліотечних файлів, які він створює. Вони розглядаються як бінарні файли бібліотек, в яких підтримується libtool середовище.