Программа запускающаяся на любом дистрибутиве

Возможно C++/qt - не самый лучший выбор. Быть может стоит обратить внимание на интерпретируемые языки (ruby, python, tcl/tk)?

Зачем? Места на CD заведомо хватит, а Tk для гуя с собой тянуть ничуть не проще. Если программа заведомо не предназначена для старых машин, использование Tk вместо Qt особых преимуществ не даст.

А лучше всего написать все на java и привесить скрипт который перед запуском основной проги будет временно инсталлить jre. Некоторые вендоры коммерческого софта так делают. Уроды

а кокова вероятность что у запустившего программу с CD будит установлен PyQT или PyGtk? Поэтому я и думаю использовать статически слинокованную программу... Но я не уверен что она пойдет на любом дистрибутиве...

Нет ну уроды не уроды, а это имеет смысл... Главное то чтоб на любом дистрибутиве пошли...

anonymous (*) (03.01.2005 13:09:32):

> Быть может стоит обратить внимание на интерпретируемые языки (ruby, python, tcl/tk)?

Весьма вредный совет. Единственный интерпретатор, не имеющий проблем с переносимостью -- стандартный sh. Даже bash-скрипт не везде одинаково сработает. А tcl/tk IMHO просто специально пишется так, чтобы быть самому с собой не совместимым.

OK. Тогда кокова вероятность что слинкованная статически прога пойдет на всех современных дистрибутивах? Это собственно и требуется... Вне зависимости от того инсталлированна ли библиотеки нужных версий. Как например Опера работает....

anonymous (*) (03.01.2005 12:32:15):

Я имею некий опыт в написании и сборке подобных программ. Это -- весьма нетривиально:

Надо ВСЕ сликовать статически (в том числе и libc и, главное, stdc++; для этого придется в качестве фронт-энда для линкера использовать gcc, а не g++). Qt 3.x не годятся (по крайней мере мне не удалось их статически собрать). Кроме того, необходимо самому собрать libc с ограниченным nsswitch, иначе эта кака все потроха за собой потянет, и по хрену ей статическая сборка; вот, пару лет назад на эти грабли я наступал: http://www.linux.org.ru/view-message.jsp?msgid=211297

И еще, способ сборки зависит от версии gcc.

Как делаю я:

gcc 3.2

Qt 1.44, собранные с конфигурацией linux-g++-static, в которой я добавил к флагам SYSCONF_CXXFLAGS и SYSCONF_CXXFLAGS_LIB опцию -fno-operator-names

glibc-2.2.5, собранная с enable-static-nss; вот опции для configure:

--host=i386-linux --enable-add-ons --disable-profile --enable-static-nss

Кусочки из Makefile'а:

ALLIBS = -L$(MYLIBC) -L$(QTLIB) -L$(X11LIB) -static -lqt -lstdc++ -lX11 -lXext -lm -ldl -lc -lnss_files -lnss_dns -lresolv

ALLINC = -I$(QTINC) -I$(X11INC) -I.

cc=gcc

CC=g++

LD=gcc

CFLAGS= -fno-operator-names -Wall -O2

Цели:

cpp.o:

$(CC) $(CFLAGS) -c -o $@ $(ALLINC) $<

.c.o:

$(cc) $(CFLAGS) -c -o $@ $(ALLINC) $<

Сборка:

$(LD) -o ${THENAME}.bin $(OBJECTS) $(ALLLIBS)

(Понятно, OBJECTS = one.o two.o etc... )

anonymous (*) (03.01.2005 14:07:22):

> Как например Опера работает....

Да уж, она, конечно, работает...

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

угу понятно... можно твою аську или e-mail если вопросы появятся...

anonymous (*) (03.01.2005 15:16:02):

> можно твою аську или e-mail если вопросы появятся...

Аськи нет, мэйл можно писАть на colonel_b@hotmail.com, только в subjе по-русски пиши, чтобы в спаме не утонуть.

Только IMHO лучше сюда вопросы, топик общеинтересный.

>> Как например Опера работает....
>
> Да уж, она, конечно, работает...

а вот этого нам тут не надо :P
она (v6.12) у меня работает и на OpenBSD в *самодельном* linux base
от slackware 10 (первое попавшееся линуксовое г. на моем столе :)))
причем умеет и ttf шрифты от иксов и с антиализингом... вот так =)

PS.
тарболл зовется opera-6.12-20030305.1-static-qt.i386.tar.gz
билд 362. в кору вылетает _не чаще_ чем на linux.

А почему нельзя на диск полжить нужные .so библиотеки и не настраивать
LD_LIBRARY_PATH перед запуском?

> А почему нельзя на диск полжить нужные .so библиотеки...

оставь это... они любят заморачивать себе мозги %)

fghj (03.01.2005 16:40:58):

> А почему нельзя на диск полжить нужные .so библиотеки и не настраивать LD_LIBRARY_PATH перед запуском?

Многовато библиотек получится. К тому же надо будет как-то настраивать этот самый LD_LIBRARY_PATH и PATH, что не всегда тривиально.

Раньше (лет 5 назад) я так и делал: клал Qt, а остальное было системное, и все работало.

Потом началось.

Сейчас даже stdc++ на последних версиях SuSE и RedHat'а не стыкуются. Но совершенно доканала меня несовместимость libc.so.6, различающихся минорными версиями.

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

Пример: пишет мне пользователь, что одна программа вдруг стала валиться по segv. ВСЕ статически слинкованно, все работало, и вдруг перестало!

Хорошо, у меня там аккаунт был, и администратор знакомый. Кстати, процитированный мной монолог http://www.linux.org.ru/view-message.jsp?msgid=211297 именно тогда родился.

Оказалось, в файле /etc/nsswitch.conf админы переставили ldap с dns.

И подобных случаев много было!

> Пример: пишет мне пользователь, что одна программа вдруг стала валиться по segv
> Оказалось, в файле /etc/nsswitch.conf админы переставили ldap с dns.

а разве подобные случаи не подпадают в разряд тестируемых перед выпуском
программы?

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

> а разве подобные случаи не подпадают в разряд тестируемых перед выпуском
> программы?

прочитал вот это: http://www.linux.org.ru/profile/signal11/view-message.jsp?msgid=211297

так это был баг в libnss_ldap? это не часть glibc я так понял?

> Столь пионЭрской поделки, как glibc2, я еще не видел.

есть еще bash и куча всего гнутого ;)

signal11 (*) (03.01.2005 17:31:44):

> а разве подобные случаи не подпадают в разряд тестируемых перед выпуском программы?

Ну, на моей машине вообще ldap'а не было. Тогда прибамбас этот был относительно новым, и я про него вообще не знал. К тому же, я ни коим боком nss не использовал, gethostbyname Xlib звала.

Но дело-то не в этом было. КОНКРЕТНАЯ версия модуля nss_ldap содержала баг, проявляющийся только при статической линковке (!). Я же не могу тестировать все возможные баги всех библиотек!

Даже если положить ВСЕ требуемые библиотеки (как раз CD, думаю, займут), каким-то образом настроить LD_LIBRARY_PATH (Интересно, как? Админы любят извращаться, ставя экзотические файловые системы, играя специфическими атрибутами и дикими комбинациями прав доступа. Или какие-нибудь дикие алиасы, ограничивающие использование LD_LIBRARY_PATH, к тому же, написанные с ошибками), все равно, любая Иксовая прога через NSS Service втихаря подгрузит локальный вариант libc.so.6 при открытии дисплея. И нет гарантии, что соответствующие модули не будут конфликтовать с теми, что лежат на CD. Я все это проходил, знаю.

signal11 (03.01.2005 17:35:03):

> так это был баг в libnss_ldap? это не часть glibc я так понял?

Правильно.

>> Столь пионЭрской поделки, как glibc2, я еще не видел.

>есть еще bash и куча всего гнутого ;)

Под "пионЭрством" я подразумевал загрузку втихаря локальной версии libc.so.6 в статически слинкованнуя прогу. А особенно комментарий из man nsswitch.conf (...With Linux, this is no problem.) IMHO так гордиться столь кривым решением могут только настоящие пЫонЭры!

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

> Зачем? Места на CD заведомо хватит, а Tk для гуя с собой тянуть ничуть не проще. Если программа заведомо не предназначена для старых машин, использование Tk вместо Qt особых преимуществ не даст.

Смотря, что за программа. Если ничего экзотического, то можно обойтись распространением скрипта и tcl/tk из дистрибутива.

> А лучше всего написать все на java и привесить скрипт который перед запуском основной проги будет временно инсталлить jre. Некоторые вендоры коммерческого софта так делают. Уроды

Тогда уж лучше сделать пакеты для основных дистрибутивов, а для остальных положить tar.gz.

> Весьма вредный совет. Единственный интерпретатор, не имеющий проблем с переносимостью -- стандартный sh. Даже bash-скрипт не везде одинаково сработает.

Только "стандартный sh" не может служить заменой qt.

> А tcl/tk IMHO просто специально пишется так, чтобы быть самому с собой не совместимым.

Почему? Сам tcl, как язык, и tk, как библиотека, вполне стабилны.

если все так плохо что даже Xlib доверять нельзя, остается одно: писать все на java, с веб-интерфейсом.вместо giu

Еще один пЫонерский рецепт:

положи все, что надо на CD и пускай chroot'ом

>если все так плохо что даже Xlib доверять нельзя, остается одно: писать >все на java, с веб-интерфейсом.вместо giu

так лучше уже написать на java и временно jre синсталить... тогда зачем web интерфейс? прекрасно GUI получится...

amm (03.01.2005 21:02:44):

> Сам tcl, как язык, и tk, как библиотека, вполне стабилны.

Я имею реальный экспириенс по работе с сим творением. К примеру, несколько убитых недель на попытку переползти с Tcl/TK 8.3.0 на Tcl/TK 8.3.1 (оказалось, невозможно в принципе! Кое-что, что работало в 8.3.0 и ранее, принципиально не работает в 8.3.1).

Вообще, на моей памяти НИ ОДИН более-менее продвинутый скрипт НИ РАЗУ не пошел на интерпретаторе, отличающемся более, чем на один номер относительно версии, на которой скрипт был отлажен (я говорю про чужиие скрипты, не свои). Всегда надо хоть немного, но подточить.

Не собираюсь спорить: я имею многолетнюю статистику. Это мое окончательное мнение.

anonymous (*) (04.01.2005 12:54:46):

>>если все так плохо что даже Xlib доверять нельзя, остается одно: писать >все на java, с веб-интерфейсом.вместо giu

>так лучше уже написать на java и временно jre синсталить...

Под текущую версию Вындуза?

Может, мне не повезло, но пока я не видел ни одной нормально работающей программы, написанной на Жабе (я имею в виду, нормально ПЕРЕНОСИМО работающей). Даже супер-пупер компании, типа Оракла, производят такие творения, что они без напильника просто не взлетают.

У меня жена лабораторную на Жабе делала. Довольно простые вещи, типа Hellow, World!, правда, с базами данных.

Все работало -- под Хрюшей.

Ради хохмы, попытались на Линухе погонять.

Даже не скомпилилось.

> Я имею реальный экспириенс по работе с сим творением. К примеру, несколько убитых недель на попытку переползти с Tcl/TK 8.3.0 на Tcl/TK 8.3.1 (оказалось, невозможно в принципе! Кое-что, что работало в 8.3.0 и ранее, принципиально не работает в 8.3.1).

Я могу поверить, что были проблемы, но в "невозможно в принципе" -- нет. Пишу под win2k, tcl 8.4.1, на rh7.2, tcl 8.4.5 скрипт запускается после простого копирования, никаких напильников.

> Вообще, на моей памяти НИ ОДИН более-менее продвинутый скрипт НИ РАЗУ не пошел на интерпретаторе, отличающемся более, чем на один номер относительно версии, на которой скрипт был отлажен (я говорю про чужиие скрипты, не свои). Всегда надо хоть немного, но подточить.

> Не собираюсь спорить: я имею многолетнюю статистику. Это мое окончательное мнение.

Да пожалуйста. Только по твоим же словам можно понять, что c++ и java ничем в этом отношении не лучше.

amm (04.01.2005 19:44:45):

> Я могу поверить, что были проблемы, но в "невозможно в принципе" -- нет.

Увы!

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

Я занимался тогда некими словарями. Мне были нужны самопальные фонетические шрифты, не имеюшие маппинга на UTF.

Усе!

А во всех весиях ДО ТОГО все работало (ну, с напильником от версии к версии, конечно).

> Пишу под win2k, tcl 8.4.1, на rh7.2, tcl 8.4.5 скрипт запускается после простого копирования, никаких напильников. Повезло!

Попробуй посложнее извратиться. Уверяю, ждет сюрприз! :-)

> Только по твоим же словам можно понять, что c++ и java ничем в этом отношении не лучше.

Да, почти так. Хотя, от ЦеПП можно добиться сносного поведения, после достаточно продолжительного танца с бубном...

Не-плюсатые Це, более-менее хорошо себя ведут.

>так лучше уже написать на java и временно jre синсталить...

>Под текущую версию Вындуза?

>Может, мне не повезло, но пока я не видел ни одной нормально работающей программы, написанной на Жабе (я имею в виду, нормально ПЕРЕНОСИМО работающей). Даже супер-пупер компании, типа Оракла, производят такие творения, что они без напильника просто не взлетают.

>У меня жена лабораторную на Жабе делала. Довольно простые вещи, типа Hellow, World!, правда, с базами данных.

>Все работало -- под Хрюшей.

>Ради хохмы, попытались на Линухе погонять.

>Даже не скомпилилось.

Так под Винду мне и не надо! мне надо чтоб под любым линуксом запускалось...

> Усе! А во всех весиях ДО ТОГО все работало (ну, с напильником от версии к версии, конечно).

Ну так проблема в отсутствии соответствующего шрифта. Плохо то, что это выяснилось при смене patch-версии (наверное, посчитали то, что это работало в 8.3.0 багом, и поправили).

...Покурил поиск на www.tcl.tk и man 3 Tcl_GetEncoding: для заданного шрифта можно написать .enc файл, в котором прописывается соответсвие между юникодовским кодом и кодом символа данного шрифта. Твой случай?

> Попробуй посложнее извратиться. Уверяю, ждет сюрприз! :-)

Верю. :) Но что поделать: работа программиста и без тикля полна сюрпризов.

amm (05.01.2005 15:42:36):

> Ну так проблема в отсутствии соответствующего шрифта.

Дык нет, проблема была в том, что в нескольких версиях, начиная с 8.3.1, i18n была кривой. Потом, вроде, починили -- под 8.4 та проблема исчезла.

Но это был только один пример.