Создание динамической библиотеки под разные версии Linux

нет. Важна только архитектура.

Да ладно, а если использовать в библиотеке какую-нибудь фичу конкретной ОС ?

Смотря от каких других системных библиотек она зависит.

http://en.wikipedia.org/wiki/Linux_Standard_Base

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

Проблемы возникнуть могут, особенно если распространять уже готовые сборки. Как правило, основные проблемы из-за разных версий glibc или stdc++, так как они определять символы версии и при линковки с другой версией могут быть несоответствия (особенно если собираешь с новой версией, а работать должна со старой).

Можно собрать билиотеку статически со всем необходимым.

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

если именно под разные версии Linux (ядра), то если программа будет дёргать только POSIX-функции, а не всякие линуксоспецифичные, то проблем быть не должно

Статически собрать динамическую библиотеку же.

Хотелось бы понять, что, возможно, придетеся менять у себя, если клиенты не смогут подцепить разработанную для них библиотеку...Методы библиотеки должны организовывать POST-запросы к некому http-серверу, а также отправлять свои логи на ftp-серверу.

Не поняла Вас...

Собирай на чём-нибудь не очень быстрообновляющемся, вроде Debian stable (ну или сколько вам там в прошлое надо).

Понять можно лишь тестируя на разных версиях разных дистрибутивов. Обычно выбирают несколько целевых окружений (что-то вроде текущей версии Ubuntu или Debian), которых будут поддерживать, уделяя остальным внимание по остаточному принципу.

Статически собрать динамическую библиотеку же.

Не поняла Вас...

как глубоко подпрыгнуть хлопнув одной ладонью - это наш простяцкий дзен :)

http://stackoverflow.com/questions/2649735/how-to-link-static-library-into-dy...

ABI ядра(системных вызовов) услово постоянно в пределах одной архитектуры/разрядности, если не играться со специфическими флагами компиляции (ядра).
Динамические библиотеки грузит ld.so из состава (g)libc, это ABI (cdecl на x86?) тоже может меняться, если того захотел компилирующий, но этим тоже никто не занимается.

Единственное, в чём может быть загвоздка - в версии этой самой glibc, т.е. если в функцию добавляется какая-то функциональность - она может присутствовать только с какой-то версии, т.е. если скосмилировать свою dll с этой версией - она запросто может не работать на более старых.
Пример из жизни - sscanf: если собрать программу с последней версией glibc, то она откажется работать на версиях старее 2.7, т.к. будет использовать функцию sscanf@GLIBC_2.7

Могут быть проблемы только на "динозавриных" системах. А еще стопроцентно будут проблемы, если эту библиотеку без исходных кодов надо распространять. Тогда она точно нигде, кроме системы, под которую ее скомпилили, работать не будет!

Т.е. отдавать им тарбол с коротенькой инструкцией сборки — не вариант?

Тогда пихайте вопрос в "коммерческое ПО".

Могут быть проблемы только на «динозавриных» системах.

Сам ты тупой динозавр

http://qt-project.org/forums/viewthread/30945 http://comments.gmane.org/gmane.comp.lib.qt.user/8033

А еще стопроцентно будут проблемы, если эту библиотеку без исходных кодов надо распространять. Тогда она точно нигде, кроме системы, под которую ее скомпилили, работать не будет!

4.2

А еще стопроцентно будут проблемы, если эту библиотеку без исходных кодов надо распространять. Тогда она точно нигде, кроме системы, под которую ее скомпилили, работать не будет!

Слишком толсто ведь... Но на практике, если не собирать со старой версией glibc и использовать дистроспецифичные либы, проблемы всё же могут возникнуть.

нет такой «ОС Linux» есть ядро Linux и окружение, получается уже что-то.

проблемы - вопрос открытый. Но ведь у программы есть жизненный цикл, так что никаких особых проблем не возникнет (если конечно менеджеры нормальные).

Докажи!

Докажи!

Лол, буду я еще перед юниорами распинаться про стабильные ABI. Тот пустобрёх, который заявил, что «она точно нигде, кроме системы, под которую ее скомпилили, работать не будет», пусть и предоставит доказательства своего утверждения.

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

Ога, ога. Соберу я ее на 64-битной системе и буду пытаться на 32-битной запускать ☺

А то и вообще: на мипсе или арме!

Ты исходное сообщение топикстартера читал вообще? Там сказано о разных версиях ОС, а не о разных аппаратных архитектурах.