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

Question

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

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

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

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

Answer 1

Я весьма весьма рекомендую использовать приложение LSB / library checker.Это быстро сообщит вам, если вы:

• Используете расширения, которые недоступны в некоторых дистрибутивах
• Вводите bash-измы в свои сценарии установки
• Используйте системные вызовы, которые доступны не во всех последних ядрах
• Зависит от нестандартных библиотек (это подскажет вам, в каких дистрибутивах их нет).
• И много-много других очень хороших проверок

Вы можете получить более подробная информация здесь а также загрузить инструмент.Им легко управлять..просто разархивируйте его, запустите perl- скрипт и направьте свой браузер на localhost ..остальное зависит от браузера.

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

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

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

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

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

Answer 2

Если вы хотите помочь своим пользователям, предоставив им скомпилированный код, лучший способ, который я знаю, - это предоставить им статически связанный двоичный файл + документацию о том, как они могут запустить двоичный файл.(Возможно, это в дополнение к предоставлению им исходного кода.) Большинство статически связанных двоичных файлов работают в большинстве дистрибутивов 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 3

В идеале вы захотите использовать GNU автоконфликт, автоматизировать, и libtool ( инструмент) чтобы создать скрипты configure и make, затем распространите библиотеку в качестве исходного кода вместе с созданными файлами configure и Makefile.в файлах.

Вот пример онлайн-книга о них.

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

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

Answer 4

Итак, вопрос в том, как разработать разделяемые библиотеки для Linux?Вы могли бы взглянуть на этот учебник или библиотека Pogram Howto.

Answer 5

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

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

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

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

Answer 6

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

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

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

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

Answer 7

Ответ Тинкертима точен.Я добавлю, что важно понимать и планировать изменения в ABI ССАГПЗ.В последнее время ситуация была довольно стабильной, и я предполагаю, что все основные дистрибутивы находятся на gcc 4.3.2 или около того.Однако каждые несколько лет некоторые перейти на ABI (особенно связанные с C ++ биты), похоже, вызывают хаос, по крайней мере, для тех, кто хочет выпускать двоичные файлы с несколькими дистрибутивами, и для пользователей, которые привыкли получать пакеты из других дистрибутивов, чем они на самом деле запускаются, и обнаруживать, что они работают.Пока происходит один из этих переходов (все дистрибутивы обновляются в своем собственном темпе), в идеале вы хотите выпускать библиотеки с ABI, поддерживающими полный спектр версий gcc, используемых вашими пользователями.