Портативные общие объекты? - PullRequest
5 голосов
/ 01 мая 2009

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

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

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

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

Ответы [ 7 ]

10 голосов
/ 01 мая 2009

I очень очень рекомендуем использовать средство проверки приложений / библиотек LSB. Он скажет вам быстро, если вы:

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

Вы можете получить дополнительную информацию здесь , а также загрузить инструмент. Его легко запустить ... просто распакуйте его, запустите скрипт на Perl и укажите ваш браузер на localhost ... остальное - браузер.

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

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

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

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

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

4 голосов
/ 02 мая 2009

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

Вот электронная книга о них.

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

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

4 голосов
/ 01 мая 2009

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

2 голосов
/ 01 мая 2009

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

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

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

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

2 голосов
/ 01 мая 2009

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

0 голосов
/ 02 мая 2009

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

0 голосов
/ 01 мая 2009

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

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

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

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

...