Переносные общие объекты?

Question

Можно ли использовать общие файлы объектов переносимым способом, например, DLL в Windows?

Мне интересно, есть ли способ предоставить скомпилированную библиотеку, готовую к использованию, для Linux. Точно так же вы можете скомпилировать DLL в Windows и его можно использовать на любой другой Windows (хорошо, а не любой другой, но на большинстве из них он может).

Возможно ли это в Linux?

EDIT:
Я только что проснулся и читать ответы. Есть очень хорошие.
Я не пытаюсь скрыть исходный код. Я просто хочу предоставить уже скомпилированную и готовую к использованию библиотеку, поэтому пользователям, не имеющим опыта компиляции, не нужно делать это самостоятельно.
Следовательно, идея состоит в том, чтобы предоставить файл .so, который работает как можно больше разных Linux.
Библиотека написана на C++, используя библиотеки STL и Boost.

Answer 1

I высоковысоко рекомендуем использовать программу LSB app/library checker. Его собираюсь рассказать вам быстро, если вы:

• ли с помощью расширений, которые не доступны на некоторых дистрибутивах
• Внести Баш-измов в установку скриптов
• Использование системных вызовов, которые не доступны во всех последних ядра
• Положитесь на нестандартных библиотек (он расскажет вам, что дистрибутивы их не хватает)
• И много, по их много других очень хороших проверок

Вы можете получить more information here, а также скачать инструмент. Его легко запускать. Просто отпустите его, запустите скрипт perl и укажите свой браузер на localhost .. остальное управляется браузером.

С помощью этого инструмента вы можете легко получить свою библиотеку/приложение LSB (для обеих версий) и упростить задачу дистрибутива-упаковщика.

Помимо этого просто используйте что-то вроде libtool (или аналогичного), чтобы убедиться, что ваша библиотека установлена ​​правильно, предоставить статический объект для людей, которые не хотят ссылаться на DSO (потребуется время для вашей библиотеки появляются в большинстве дистрибутивов, поэтому пишу переносную программу, я не могу рассчитывать на ее присутствие) и хорошо прокомментируйте ваш публичный интерфейс.

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

Действительно, проверьте, есть ли у вас проблемы с переносимостью, которые потребовали бы год с библиотекой в ​​дикой природе, чтобы получить в противном случае.

Наконец, попробуйте сделать вашу библиотеку легко отбросить «в дереве», поэтому мне не нужно статически ссылаться на нее. Как я уже сказал, это может занять пару лет, прежде чем оно станет распространенным в большинстве дистрибутивов. Мне гораздо проще просто захватить ваш код, отбросить его в src/lib и использовать его до тех пор, пока ваша библиотека не будет распространена. И, пожалуйста, пожалуйста, дайте мне модульные тесты, TAP (протокол тестирования любого протокола) - это хороший и переносимый способ сделать это.Если я взломаю вашу библиотеку, мне нужно знать (быстро), если я ее сломал, особенно при ее изменении в дереве или en situ (если DSO существует).

Answer 2

Просто поместите файл .so в/usr/lib может, но вы, вероятно, испортите схему, которую ваш дистрибутив имеет для управления библиотеками.

Взгляните на стандартную базу linux. Это самая близкая вещь, которую вы найдете в общей платформе среди дистрибутивов Linux.

http://www.linuxfoundation.org/collaborate/workgroups/lsb

Что вы пытаетесь достичь?

Answer 3

Итак, вопрос в том, как разрабатывать общие библиотеки для Linux? Вы можете взглянуть на this tutorial или the Pogram Library Howto.

Answer 4

Я знаю, что вы просите. Для Windows MSFT тщательно объединила DLL, поэтому ваши библиотеки DLL обычно совместимы практически со всеми версиями Windows, поэтому вы называете это «портативным».

К сожалению, в Linux слишком много вариантов (и каждый думает быть «разными», чтобы заработать деньги), так что вы не можете получить такие же преимущества, как Windows, и поэтому у нас есть много одинаковых пакетов, скомпилированных для разных дистрибутивов , версия дистрибутива, тип CPU, ...

Некоторые говорят, что проблема вызвана архитектурой процессора (CPU), но это не так. Даже на одной арке между дистрибутивами все еще существует. После того, как вы действительно попытались выпустить двоичный пакет, вы бы знали, насколько это сложно - даже зависимость C библиотеки времени выполнения очень трудно поддерживать. Linux-ОС не хватает слишком много материала, поэтому почти все службы связаны с проблемой зависимости.

Обычно вы можете создавать только двоичные файлы, совместимые с некоторыми дистрибутивами (или несколько дистрибутивов, если вам повезет). Вот почему выпуск Linux-программ в двоичном формате всегда прикручивается, если не связан с каким-то дистрибутивом, как Ubuntu, Debian или RH.

Answer 5

Если вы хотите помочь своим пользователям, предоставив им скомпилированный код, лучший способ, который я знаю, - предоставить им статически связанную двоичную + документацию о том, как они могут запускать двоичный файл. (Это, возможно, в дополнение к предоставлению им исходного кода.) Большинство статически связанных двоичных файлов работают с большинством дистрибутивов Linux той же архитектуры (32-разрядные (x86) статически связанные двоичные файлы работают на 64-битных (amd64)). Неудивительно, что Skype предоставляет статически связанную загрузку Linux.

Назад к вопросу о вашей библиотеке.Даже если вы являетесь экспертом в написании разделяемых библиотек в Linux и не спешите минимизировать зависимости, чтобы ваша общая библиотека работала в разных дистрибутивах Linux, включая старые и новые версии, нет никакого способа гарантировать, что она будет работать в будущем (скажем, 2 года). Скорее всего, вам удастся сохранить файл .so, т. Е. Делать небольшие изменения снова и снова, поэтому .so-файл становится совместимым с более новыми версиями дистрибутивов Linux. Это не забавно делать в течение длительного времени, и это значительно снижает вашу производительность: время, затрачиваемое на поддержание совместимости с библиотекой, было бы намного лучше потрачено на, например, улучшая функциональность, эффективность, безопасность и т. д. программного обеспечения.

Обратите внимание, что очень легко нарушить ваши пользователи, предоставив библиотеку в форме .so, которая не работает в их системе. (И у вас нет сверхдержавы, чтобы он работал на всех системах Linux, поэтому эта ситуация неизбежна.) Предоставляете ли вы также 32-разрядные и 64-разрядные версии, включая x86, PowerPC, ARM и т. Д.? Если .so-файл работает только на Debian, Ubuntu и Red Hat (потому что у вас нет времени на перенос файла в другие дистрибутивы), вы, скорее всего, будете расстраивать пользователей SUSE и Gentoo (и многое другое).

Answer 6

В идеале, вы хотите использовать GNU autoconf, automake и libtool создать настроить и сделать скрипты, а затем распространять библиотеку в качестве источника с настроечным и Makefile.in файлами.

Вот online book о них.

./configure; make; make install довольно стандартный в Linux.

Корень проблемы заключается в том, что Linux работает на разных процессорах. Вы не можете просто полагаться на процессор, поддерживающий инструкции x86, такие как Windows (для большинства версий: Itanium (XP и новее) и Alpha (NT 4.0) являются исключениями).

Answer 7

Ответ Тинкертима на месте. Добавлю, что важно понимать и планировать изменения в gcc's ABI. В последнее время ситуация довольно стабильна, и я думаю, что все основные дистрибутивы находятся на gcc 4.3.2 или около того. Однако каждые несколько лет некоторые change to the ABI (особенно связанные с C++ биты), по-видимому, вызывают хаос, по крайней мере, для тех, кто хочет выпустить бинарные файлы перекрестного дистрибутива и для пользователей, которые привыкли собирать пакеты из других дистрибутивов, чем они фактически запускают, и находят они работают. В то время как один из этих переходов происходит (все обновления дистрибутива в своем собственном темпе), вы в идеале хотите освободить библиотеки с ABI, поддерживая полный диапазон версий gcc, используемых вашими пользователями.