Должен ли я создавать .a или .so при упаковке моего кода в качестве библиотеки?

Question

У меня есть библиотека программного обеспечения, и я использовал для создания .a файлов, так что люди могут установить их и ссылки на них: g++ foo.o -L/path/to -llibrary

Но теперь я часто сталкиваюсь сторонние библиотеки, где только .so файлы доступны (вместо .a), и вы просто связываете их без переключателя -l, например g++ foo.o /path/to/liblibrary.so.

Каковы различия между этими решениями? Должен ли я предпочитаю создавать файлы .so для пользователей моей библиотеки?

Answer 1

Как правило, libfoo.a является статической библиотекой, и libfoo.so является общей библиотекой. Вы можете использовать те же самые -L/-l параметры компоновщика как статические, так и общие. Или вы можете назвать полный путь к lib со статическим или общим. Часто библиотеки создаются как статические, так и общие для предоставления разработчикам приложений, выбор которых они хотят.

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

Код из общей библиотеки не является частью исполняемого файла. Есть только некоторые крючки на месте, чтобы сделать исполняемый файл осведомленным о имени библиотеки, в которой он нуждается. Для запуска вашего приложения общая библиотека должна присутствовать в пути поиска lib (например, $LD_LIBRARY_PATH).

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

Answer 2

Хороший обзор статических, динамических и совместно загружаемых библиотек на

http://www.yolinux.com/TUTORIALS/LibraryArchives-StaticAndDynamic.html

Answer 3

Некоторые функции, которые не вызываются из комментариев, которые я видел до сих пор.

Статическое связывание (.a/.lib)
Совместное использование памяти между этими единицами компиляции, как правило, хорошо, потому что они должны (? Будет) все использовать тот же среду выполнения.

Статическая связь означает, что вы избегаете «dll hell», но стоимость заключается в перекомпиляции, чтобы вообще использовать какие-либо изменения. статическая привязка к общим библиотекам (.so) может привести к странным результатам, если у вас более одной такой разделяемой библиотеки, используемой конечным исполняемым файлом - глобальные переменные могут существовать несколько раз, а какие используются и когда они инициализируются, могут привести к совершенно другому ад.

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

Shared/динамические библиотеки (.so/.dll)
Совместное использование памяти между этими единицами компиляции могут быть опасными, поскольку они могут выбрать использовать различные среды выполнения. Это может означать, что вы предоставляете разные общие/динамические библиотеки на основе отладки/выпуска или одиночной/многопоточной или ...

Общие библиотеки (.so) менее подвержены «dll hell», а затем Dynamic libraries (.dll) поскольку они включают опции для довольно конкретного управления версиями.

Компиляция с .so будет захватывать информацию о версии внутри файла (трудно подделать), чтобы вы получили довольно специфическое использование .so. Компиляция с .lib/.dll дает только базовое имя файла, любое управление версиями выполняется разработчиком (с помощью илименования или вручную загрузки библиотеки и проверки сведений о версии вручную)

Библиотека должна будет отправить с помощью конечный продукт (кто-то может его забрать и использовать)

Answer 4

Но теперь я часто встречаюсь со сторонними библиотеками, где доступны только файлы .so [...], и вы просто связываете их без -l переключатель, например g ++ foo.o /path/to/liblibrary.so.

JFYI, если вы ссылаетесь на общую библиотеку, которая не имеет набор игнорирован (сравните с readelf -a liblibrary.so), вы будете в конечном итоге положить указанный путь liblibrary.so в целевой объект (исполняемый файл или другой разделяемой библиотеки), и это обычно нежелательно, поскольку у пользователей есть свои идеи о том, куда поместить программу и связанные с ней файлы. Предпочтительным способом является использование -L/path/to -llibrary, возможно, вместе с -Wl, -rpath,/whatever/path/to, если это конечный путь (такие решения для принятия решений выполняются, например, дистрибутивами Linux).

Должен ли я использовать файлы .so для пользователей моей библиотеки?

Если вы распространяете исходный код, пользователь сделает конкретный выбор.