ПО для Линукса [флейм]

[ритт]

неплохая статья, но, к сожалению, много мелких ошибок. ни к чему заострять на них внимание - просто не воспринимайте её как истинно верную - используйте /dev/head...
кстати, доходчиво сказано про -static (man gcc)

[xintrea]

Ключевой вопрос - как влинковывать либы? Желательно, толпою, без плясок с получением *.a файла для каждой либы из исходников.

я в растерянности - как отвечать на этот вопрос?
откуда *.a-файлы возьмутся, если в пакетах дистра их нет и собирать их ты не хочешь?
./configure --prefix=/tmp/dest --enable-static ... && make && make install

Существуют либы, в которых configure нет --enable-static. Что с ними делать? Дописывать configure, чтобы получить статическую версию? Дык это сколько времени потратить надо, чтоб расковырять, поправить, дописать. Причем ковыряешься не со своим проектом, а доделываешь левый, который пришлось использовать.

И такой вопрос - когда создается статическая либа, использутся ли в ней вызова других динамических либ? Подозреваю, что используется, посему надо озаботится статической сборкой либ, от которых зависит нужная. А потом озаботится статической сборкой нужной либы, но так, чтобы она подлинковала к себе статические сборки либ, от которых она зависит. Мне страшно представить такую работу.

и, быть может, тебе вовсе и не надо полностью статическую сборку? libm есть, lua и sdl симпатишнее выглядят в динамических либах...

Зачастую, lua и sdl требуются вполне конкретных версий, посему использовать динамические либы дистра пользователя - это значит обеспечить глюки и неработу программы. Вот например, что у меня с Оперой 9.62 было http://operafan.net/forum/topic_6508_0.html. И не сказать, что не работает, но и работой такое трудно назвать.

может будет достаточно таскать с собой нужные динамические либы +

LD_LIBRARY_PATH=`pwd`/lib:$LD_LIBRARY_PATH;export LD_LIBRARY_PATH

Но будут ли принесенные с программой динамические либы работать как надо? Ведь они зачастую используют код из других динамических либ, которые неизвестно каких версий у пользователя (см. начало этого поста).


Нам нужно получить "вещь в себе", которая будет содержать весь нужный код. Какой код у разработчика - такой код и у пользователя. Только так можно достигнуть удовлетворительной степени повторяемости результата. Полумеры в стиле "вот это можно динамически грузить, а вот это, скорее всего, лучше статически иметь рядом" нам не подходят. Как сказал товарищ Dandy, "...в программировании нет маленькой вероятности, большой вероятности, очень маленькой вероятности и т. п. Вероятность в программировании определяется булевской переменной: или она есть, или её нет. Никаких "сомнений" быть не может." Вот так, практически по Булгакову. Внимем же голосу рассудка, и не будем использовать решения второй свежести!

[Dendy]

Но будут ли принесенные с программой динамические либы работать как надо? Ведь они зачастую используют код из других динамических либ, которые неизвестно каких версий у пользователя (см. начало этого поста).

Встречный вопрос. А каким образом статическая сборка решит именно эту проблему? Вызовы извне ведь останутся ровно те же что и при статической сборке. Моё мнение (подкреплённое только теорией) - вещь в себе лучше создавать таская динамические библиотеки в отдельной директории. В конце концов, что если на каком-то этапе вы захотите создать больше одного исполняемого файла?

Как сказал товарищ Dandy...

Я тоже этот фильм смотрел.

[ритт]

"второй свежести"?

> http://operafan.net/forum/topic_6508_0.html

The requested URL /forum/topic_6508_0.html was not found on this server.

> Существуют либы, в которых configure нет --enable-static. Что с ними делать?
если не все, то почти все основные либы в линухах имеют опции --*-static --*-shared. причём, куда чаще можно встретить отсутствие второй опции...
<...snip...>

> Зачастую, lua и sdl требуются вполне конкретных версий, посему использовать динамические либы дистра пользователя...
вот я и говорю - положи их рядом со своим бинарём. если это сдл, то там всего-то обычно огг, ворбис, опенал + разное по-мелочи, причём, первые три вроде как бинарно совместимы с более старыми версиями в пределах мажорок (в любом случае, required dependencies ещё никто не отменял); если это луа, то вообще всё просто - "левых" зависимостей не имеет (ну, или вкомпиль луа в свой бинарь).

> Но будут ли принесенные с программой динамические либы работать как надо?
а что мешает? к примеру - astromenace - замечательная игрушка в своём роде. когда я о ней впервые узнал, она ещё была закрыта и можно было скачать лишь бинарные сборки под разные ОС. никаких дэбов и ибилдов - лишь два бинаря под x86 и x86_64 + папки lib32 и lib64 {libalut.so.0, libogg.so.0, libopenal.so.0, libSDL-1.2.so.0, libvorbis.so.0, libvorbisfile.so.3, libstdc++.so.6}. если не ошибаюсь, собрано всё это было под glibc-2.2. и ведь всё работает! независимо от того, что у меня glibc более свежая, более свежие либы из lib64 {...} имеются в /usr/lib, а всё это зверьё собрано с оптимизацией под k8!
не думаю, что разработчик astromenace шёл к этому решению 10 лет...ну, или хотя бы пару лет...

а вот откармливать статического монстра, вкомпиливая в него всё и вся - совсем не гут. есть несколько подводных камней, которые позже могут "всплыть", например, при работе с сетью. кстати, glibc собирается с использованием "упрощённых" заголовков ядра + указывается самая старая версия интерфейса, с которым glibc будет работать - вполне может получиться, что твой статический монстр банально не запустится на более старых ядрах (тут я не утверждаю, т.к. личного опыта по откармливанию монстров не имел)

[xintrea]

Поправочка - http://operafan.net/forum/topic_6508_0.html.

Хорошо, посмотрю астроменанс. C Qt посмотрел как qdevelop устроен, принцип, похоже, тот же. Плохо только, что сий метод до конца проблему не решает. Я так понимаю, что для сборки надо будет выбрать дистр подревнее, и на нем все делать? Без виртуалки, похоже, не обойтись, но хотябы билдферму не придется городить.

не думаю, что разработчик astromenace шёл к этому решению 10 лет...ну, или хотя бы пару лет

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

Интернет всего полтора года как стал безлимитным, а до этого либы/проги/обновления не покачаешь, не поэкспериментируешь, линухом нормально не попользуешься, трижды думаешь "а стоит ли качать?". Точнее, покачать то можно, но зарплаты не хватит трафф оплатить. Вот передо мной лежат пять DVD болванок с 23 гигами репозитария убунты, выкачанные на предприятии.

Проект тоже год назад появился http://xintrea.googlepages.com/, экспериментальный - оценить время, сложность разработки, возможности распространения. Вот на распространении я и споткнулся, например рас http://www.linux.org.ru/view-message.jsp?msgid=2559877&page=1, два http://linuxforum.ru/index.php?showtopic=69775&hl=%EF%EE%EF%F0%FB%E3%F3%ED%F7%E8%EA.

Десять лет линуха без интернета - это "фак, почему эта прога не встает?", "фак, а где взять либы?", "фак, а почему эта прога работает на redhat, и не заводится на mandrake?", "фак, а почему эта прога работает на mandrake, и не заводится на redhat?", "а как сделать так чтоб с дистра на дистр не перетыкаться?". И сборка сопровождается действиями в стиле "запишем на бумажечку, чего нам не хватает, сходим на работу, скачаем, придем вечером домой, попробуем поставить, и может быть заработает. Неприятно правда, что такое прокатывает один раз из 10". ну и т.д.

[ритт]

"рас и два" улыбнуло...грустный смайл по поводу динамического вызова альсы - тоже
и про патчи, и про "глубинные проблемы"...вообще, много смешного...
а ведь все проблемы из-за нежелания поделиться кодом на пару с незнанием как этот-самый код закрывать.
не обижайся, но ты ведь _действительно_ считал/считаешь, что autotools - костыль, работающий в 80% случаев, а статическая сборка, выполненная под бубунтой, будет запускаться и под старой шапкой, и под гентой, и под рхел, и в разных бздях

а в "ёжика" обязательно погамаю на досуге...

зы. ссылочка (на операфан) так и отдаёт 404. мб у них регаться надо для просмотра?

[xintrea]

зы. ссылочка (на операфан) так и отдаёт 404. мб у них регаться надо для просмотра?

Не, это оказывается двиг нашего форума ссылки искажает. Вот без URL тегов.

http://operafan.net/forum/topic_6508_0.html

Сцук, меня глюки преследуют на каждом шагу!

ты ведь _действительно_ считал/считаешь, что autotools - костыль, работающий в 80% случаев

Да, в пределах одной ветки ядра, в пределах одной аппаратной платформы 80% - это на самом деле очень плохой показатель, если затыки происходят совершенно по левым причинам. Да и трудно найти пользователя, который самостоятельно поймет, какие dev-пакеты нужно поставить (да и вообще, что их надо ставить),  чтоб всё чисто собралось. Autotools - не выход вообще.

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

Нет, я расчитываю, что будет грузиться хотя бы в пределах одной ветки ядра и одной аппаратной платформы. Для этого и делал, кстати, отдельно сборку под ветку 2.4, отдельно под 2.6. Но практика показывает, что оно не всегда работает даже если ядро, платформа, и libc одинаковые. Вот эта удручает.

[xintrea]

Фак, да что ета такое, и без URL тегов урл сам собой определяется и тоже искажается.

С пробелами:

http : // operafan.net / forum / index.php ? topic = 6508.0

[Admin]

встроенные модули rewrite посчитали его за URL нашего форума
вот и преобразили))

[ритт]

80% - это на самом деле очень плохой показатель, если затыки происходят совершенно по левым причинам. Да и трудно найти пользователя, который самостоятельно поймет, какие dev-пакеты нужно поставить (да и вообще, что их надо ставить),  чтоб всё чисто собралось. Autotools - не выход вообще.

в том-то и загвоздка, что пользователи берутся собирать пакеты из тарболлов, не зная "какие dev-пакеты нужно поставить (да и вообще, что их надо ставить)". аutotools - вообще не для юзверя, аutotools - для оператора/рута/мэинтайнера. для юзверя (только) официальные репы, man и гугл.
я чёрт-ти знает сколько уже обновляюсь исключительно из исходников волшебным трио "./configure ... && make && make install" и почти все те немногочисленные проблемы, которые были с конфигурой, были по причине _моих_ кривых рук и забывчивой башки; несколько раз из-за скола на камне на старой машине; и лишь считанные разы - из-за жутко устаревшего пакета (для таких всегда имеются патчи как в коммунити, так и в лучших репах мира - достаточно один раз столкнуться) или из-за слишком новой версии (последний раз сталкивался с несовместимостью интерфейсов, когда findutils уже обновили интерфейс, а glibc ещё не подтянули). всё!
и если xorg у меня стоИт в "нестандартной" /opt/X11R7, то я не забываю перед конфигурой выполнить что-то вроде

Код:

for file in $(grep -lr "X11R6" *)
do
  sed -i "s@/usr/X11R6@/opt/X11R7@g" $file
done

итого:

> 99% - это на самом деле весьма неплохой показатель, особенно, если затыки в большинстве случаев происходят совершенно по смешным причинам.

[Detonator]

Да уж. Столько проблем из-за желания сэкономить 5 т.р. за лицензионную винду.
Кто нибудь заплатил бы за линукс 5 т.р. если бы все проблемы с инсталляциями софта исчезли?

[Dendy]

Да уж. Столько проблем из-за желания сэкономить 5 т.р. за лицензионную винду.

Пожалуйста, не нужно выдавать свои желания за чужие.

[xintrea]

Да уж. Столько проблем из-за желания сэкономить 5 т.р. за лицензионную винду.
Кто нибудь заплатил бы за линукс 5 т.р. если бы все проблемы с инсталляциями софта исчезли?

Думаю, что мало бы кто заплатил.

[BRE]

Кто нибудь заплатил бы за линукс 5 т.р. если бы все проблемы с инсталляциями софта исчезли?

А за венду, по собственной воле, кто нибудь заплатил?

[-QT-]

Да уж. Столько проблем из-за желания сэкономить 5 т.р. за лицензионную винду. ...

И еще за лицензионный антивирус ...
                                 ... фотошоп ...
                                 ... тридемарк ...
                                 ... офисный пакет ...
                                 и т.д.