Библиотеки с расширениями so, la, a - какую использовать?

https://stackoverflow.com/questions/12237282/whats-the-difference-between-so-...

Вопрос: что подразумевается под «использовать»?

слинковать

Статически a
Динамически so

Инфа соточка?

Использовать систему сборки.

двухосточка

.a от слова Archive, это архив с .o файлами .so от слова Shared Objects, объекты общего пользования

Я почему спросил. Потому что мог заблуждаться. Допустим

libQt5Core.la
libQt5Core.prl
libQt5Core.so -> libQt5Core.so.5.9.1
libQt5Core.so.5 -> libQt5Core.so.5.9.1
libQt5Core.so.5.9 -> libQt5Core.so.5.9.1
libQt5Core.so.5.9.1

ldd libQt5Gui.so
libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6

т.е. никакой роли для ликовки so-библиотек файл a не играет?

Библиотеки с расширениями so, la, a - какую использовать?

Иди в винду и «используй» dll

И еще вопрос как использовать объектные файлы, сделанные другим компилятором?

учитывая C++ в тегах, есть вероятность, что никак. но бывают исключения.

Ты видимо слишком любишь m$ :)

В винде, lib файлы используются при линковке dll, что бы линкер мог построить таблицу импорта, и содержат в принципе заглушки функций из dll, которые ссылаются на реальные функции из dll. Как разрешаются там ссылки на данные, я если честно не в курсе.

В so файлах вся необходимая для линковщика инфа уже есть.

Как заметил анонимус, a файлы это архивы обьектников, называть их библиотеками, конечно можно, но по сути это просто удобный способ переносить кучу обьектников в одном файле, и тут процесс линковки ничем особо не отличается от линковки самих обьектов, архив распаковывается, обьектники линкуются к целевому бинарнику.

Всегда, когда требовалось линковаться с SO, если не было la или a, то приходилось явно указывать файл, например LIBS+= -l /usr/lib/x86_64-linux-gnu/libXext.so.6

4.2 даже в условиях qmake. Линкер ищет либу при использовании флага -l<name> по шаблону lib<name>.{so,a}.

Линкер ищет либу при использовании флага -l<name> по шаблону lib<name>.{so,a}

Ясно. Как много я не знаю про эту Вселенную... А ведь это просто GCC, даже не qmake-специфичная вещь. Хотя не раз наблюдал что некоторые so файлы требовали указания не только so он и их версии после so.1.2.3 Видимо что-то не так было настроено или указано, хз.

Соль как раз в том, что линкер не ищет чего то после суффиксов a|so. А всё это именование с версией в имени файла, костыль вместо майкрософтовских манифестов, которые позволяют в либу ряд стандартных, и много (х3 какой лимит) кастомных пар ключ/значение записать для хранения метаинформации. В юникс подобных, почему то такой подход не возник, и все кому надо, делают сиё вручную, через функции аля get_lib_version.

LIBS+= -l /usr/lib/x86_64-linux-gnu/libXext.so.6

Никогда не видел, чтобы кто-то линковал так so'шки. Вот так нужно:

LIBS += -L/usr/lib/x86_64-linux-gnu/ -lXext

А вот a'шки можно и тупо:

LIBS += /usr/lib/x86_64-linux-gnu/libXext.a

и содержат в принципе заглушки функций из dll, которые ссылаются на реальные функции из dll

Я такое и с a'шками видел. Вместо нормальных объектников там были заглушки, а рядом so'шка. С какой целью не в курсе.

Самое убогое, что там ещё и порядок линковки надо соблюдать.

Проблемы с boost в Ubuntu (комментарий)
bbqscreen_client (комментарий)

Интересно, мне не попадалось. А где?

Библиотеки с расширениями .so, .la, .a - какую использовать?

Используй .dylib!

А как поступать в ситуации, когда в системе gcc 4.4, а для сборки либы нужно 4.8, я думал, что могу собрать либу на другой системе и использовать у себя?

В каких-то проприетарных SDK к каким-то карманным девайсам. Уже не вспомню, давно сталкивался.

Ну и как пример тебе такого решения, это библиотеки MinGW:

https://stackoverflow.com/questions/13998575/mingw-creating-dll-a-files-what-...

Ну библиотеки mingw подчиняются тем же законам, что и все остальные виндовые библиотеки, по определению. По крайней мере, пока они свой загрузчик для винды не сделают.

Вроде как эти lib и dll.a/a отличаются. Хотя я в ту степь особо не копал.

Скорее всего не получится так.

Если ABI не поломан и зависимостей от конкретной libc нет, может и взлететь. Но не факт.

Если ABI не поломан и зависимостей от конкретной libc нет, может и взлететь. Но не факт.

когда ты собираешь крестокод новым G++ — он прибивается гвоздями к новым кишкам libstdc++, которые не будут найдены при линковке более старым тулчейном.

совместимость ABI не спасет.

конкретно для glibc есть костыли, чтобы это порешать, для C++ решения не знаю.

edit: а кишки нового libstdc++, в свою очередь, скорее всего будут требовать более нового glibc, кстати.

Если ABI не поломан и зависимостей от конкретной libc нет, может и взлететь. Но не факт.

Есть еще хаки, чтоб собирать новыми версиями и не требовать новых символов:

https://dxr.mozilla.org/mozilla-beta/source/build/unix/stdc compat/stdc com...

конкретно для glibc есть костыли, чтобы это порешать, для C++ решения не знаю.

Да точно такие же костыли есть, я собираю новым gcc, а релиз требует libstdc++ >= 4.8. Понятно, что новое из C++17, например, так не прикрутить, но для С++11/14 вполне хватает.

so - это разделяемая библиотека. Существуюет в единственном экземпляре, и может использоваться сразу многими приложениями

a - это статическая библиотека, по сути это просто архив с набором объектных файлов которые прилинковываются к каждому приложению которое использует библиотеку.

.a желательно избегать, поскольку они раздувают бинарники, их неудобно линковать (все зависимости библиотеки с которой ты линкуешься нужно указывать явно, в случае .so же они обработаются автоматически; также нужно следить за порядком линковки) и они препятствуют обновлениию third party кода (т.е. если .so можно обновить на новую версию где была исправлена уязвимость, с .a придётся только пересобирать всех потребителей). Плюсов у них только чуть меньший оверхед на вызовы.

.la это вообще не библиотека, а костыль от костыля libtool, который решает описанную проблему с зависимостями. Т.е. если линковаться через libtool она может сама вытащить зависимости из .la файлов. От libtool лучше тоже держаться подальше, ибо это устаревший набор костылей.

О как. Я не плюсовик и нюансов не знал.