Запуск приложения в любом дистрибутиве Linux.

[kuzulis]

Правильно ли я понял? Glibc собрана у меня как shared,а мне ее нужно пересобрать как static? Если да, то у меня возник ряд вопросов:
1 - как это сделать (думую в гугле найду)
2 - что-нибудь нужно будет менять в проекте?например, указывать пути к библиотекам

Можно попробовать собрать Glibc отдельно от той Glibc  которая установлена в системе. Т.е. вообще "закинуть" готовую static Glibc  в другие директории и т.п. А уже в вашем проекте указать пути к этой static Glibc.  т.е. НЕ трогать shared Glibc системы, а сделать параллельно свою static Glibc. Думаю идея понятна .

3 - и не рухнет ли ubuntu после сборки? это же по идее системная библиотека?

Дык придется пересобирать ВСЮ бубунту тогда .  Это уже попахивает LFS или CLFS и т.п.
т.е. см. выше что я написал. ИМХО, должно "прокатить"

4 - и будет ли прога работать в системах с более раннеми версиями glibc?

если удастся статически слинковать ваше приложение с Glibc  - то по идее должно везде работать.

---------
ЗЫ: Как вариант - можно взять сырцы Glibc и просто подключить их *.h и *.cpp/c к вашему проекту...

ЗЫЗЫ: но для этого необходимо собрать статически Glibc, GCC и т.п.  т.к. может быть, что-то понадобится еще. ИМХО.

[Alex Custov]

с glibc тоже есть ньюансы - там используются NSS плагины, и они по-умолчанию всегда shared. Чтобы из сделать static, надо передавать ключ --enable-static-nss при компиляции glibc и добавлять новые библиотеки к компилируемой программе (какие не помню)

И всё равно сделать один бинарник под все дистрибутивы имхо довольно геморно и непонятно зачем.

[kuzulis]

И всё равно сделать один бинарник под все дистрибутивы имхо довольно геморно и непонятно зачем.

+1024

[garryHotDog]

например мне нужно, что бы он работал в CentOs и Ubuntu, а не собирать в каждом дистрибутиве отдельно...и к тому же в CentOs Qt 4.2 (другую версию не удалось установить ?!), а в Ubuntu 4.6....и версия проги с qt 4.6 работает лучше - именно поэтому думал собирать в убунту и запускать в CentOs!

[break]

на счет геморно - согласен но это сложная задача вот и геморно
очень даже понятно зачем - для удобства - дрова NVidia например очень удобно иметь одним бинарником под все Linux системы

[sendevent]

статическая линковка кьют, на сколько я понимаю, похерит условие LGPL о возомжности пользователю заюзать свою версию, так что нужна либо лицензия на кьют, либо наглость =)
нашел тулзу: autopackage
минусы:
довольно вялое сообщество, авторы то экзамены сдают, то аврал на работе разгребают, сайт полурабочий, документация не фонтан, брал из свн - GTK|Qt морды не собираются, результирующий бинарник (именно самого приложения, без учета ресурсов) получается в разы больше (при этом, возможно, вышеперчисленное - просто результат моего поверхностного знакомства с сабжем).
плюсы:
берет на себя рутину по обходу проблем с glibc и бинарной совместимостью (про ABI - довольно подробно у них же на сайте), выполняет функции инсталлятора, предоставляет API для повышения "перемещаемости" приложения (чтото вроде QDesktopServices::storageLocation ( StandardLocation type )), проверяет наличие требуемых зависимостей и, при необходимости, позволяет докачать (если нет wget - само скачивает) - кьют с собой тащить не нужно.

на мой взгляд, проект скорее полумертв, чем полужив, да и повозиться нормально - все руки не доходят, но после довольно поверхностного знакомства результат пока радует - сборка из-под open suse 11.2 работает под последней федорой (не помню цифру, вроде 13 - на днях релизнулась), на других дистрах еще не тестировал. если целевые платформы это только линуксы - довольно приятное решение, видимо. если еще и вин/мак - телодвижений надо побольше, но всяко меньше, чем всё делать вручную (тем более не совсем понятно, что здесь входит во "всё").

зы. про "непонятно зачем" - народ наверное имеет ввиду, что можно распространять в исходниках, мол, "проприетарные поделки" никому тут нафиг не сдались =)

[Alex Custov]

дрова NVidia например очень удобно иметь одним бинарником под все Linux системы

но ведь дрова NVidia - НЕ один бинарник под все Linux системы. Внутри архива хранятся предкомпилированные модули для определённых ядер (отчего архив имеет такой конский размер). Если предкомпилированные модули не подходят для твоей системы, то ядерный модуль компилируется автоматически.

В Linux принято делать пакеты для каждого дистрибутва.

[break]

но ведь дрова NVidia - НЕ один бинарник под все Linux системы. Внутри архива хранятся предкомпилированные модули для определённых ядер

Я собственно думал что автора это устроит - остальные способы слишком опасны и трудоемки, если возможны вообще

[brankovic]

Понимаю что тема мёртвая, но напишу-таки 'правильный ответ' для гуглящих (сам только что искал)

Вообще проблема возникла такая же, но с wxWidgets, как запаковать .so-шки, чтобы пускалось на другом дистрибутиве (в моём случае и архитектура разная: надо на debian amd64 запустить прогу с убунту x86).

Нашёл в переписке http://www.mail-archive.com/linux-development-apps@senator-bedfellow.mit.edu/msg01043.html письмо про "Subject: Re: Running an app with a different libc so than the system default?"

Суть в том, что в бинарнике жёстко зашита ссылка на /lib/ld-linux.so.2, поэтому нельзя пользоваться LD_PRELOAD/LD_LIBRARY_PATH.  Итак, берём
1) .so-шки выданные ldd my-app, в том числе libc и libstdc++
2) ld-linux.so.2

, исполняемый файл пусть будет my-app и лежит в директории app, либы из 1, 2 кладём в app/libs

запускаем так:

Код:

$app/libs/ld-linux.so.2 --library-path app/libs app/my-app

[NicK]

Понимаю что тема мёртвая, но напишу-таки 'правильный ответ' для гуглящих (сам только что искал)

Вообще проблема возникла такая же, но с wxWidgets, как запаковать .so-шки, чтобы пускалось на другом дистрибутиве (в моём случае и архитектура разная: надо на debian amd64 запустить прогу с убунту x86).

Нашёл в переписке http://www.mail-archive.com/linux-development-apps@senator-bedfellow.mit.edu/msg01043.html письмо про "Subject: Re: Running an app with a different libc so than the system default?"

Суть в том, что в бинарнике жёстко зашита ссылка на /lib/ld-linux.so.2, поэтому нельзя пользоваться LD_PRELOAD/LD_LIBRARY_PATH.  Итак, с той системы, где собиралось берём
1) .so-шки выданные ldd my-app, в том числе libc и libstdc++
2) ld-linux.so.2

запускаем так:

Код:

$app/libs/ld-linux.so.2 --library-path app/libs ./my-app

Тема не мертвая, а до сих пор актуальная. до этого момента  не придумал ничего лучше, чем установка в virtualbox каждого дистрибутива и сборкой под него. С ld-linux.so.2 надо будет поробовать. В любом случае спасибо.

[crossly]

до этого момента  не придумал ничего лучше, чем установка в virtualbox каждого дистрибутива и сборкой под него.

сборка под конкретный дистр есть linux-way.... именно такой поуть обеспечивает целостность и стабильность системы в целом... и не надо тащить с привычки с винды в линукс... он от этого лучше не станет...

[tim474]

но ведь дрова NVidia - НЕ один бинарник под все Linux системы. Внутри архива хранятся предкомпилированные модули для определённых ядер (отчего архив имеет такой конский размер). Если предкомпилированные модули не подходят для твоей системы, то ядерный модуль компилируется автоматически.

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

[garryHotDog]

лично я для себя выбрал такой вариант: для каждой системы (а у меня их 2 Ubuntu и CentOS) - собираю отдельно....не совсем идеально - зато практично и самое главное РАБОТАЕТ!!!