LINUX.ORG.RU

Сообщения Nihilist

 

Maintainer's wiki

Вот ищу вот сабж. Хотелось бы иметь много инфы в одном месте. Что порекоммендуете?

Проще всего работать с пакетами GNU Autotools
./configure --prefix=/opt/nonexistent блаблабла && make && DESTDIR="..." make install

Автотулз у меня на ура пошли. трабли были разве что с пакетом jpegsrc. Он давно не обновлялся, года так с 96го. И автотулз там тоже не новые были использованы. DESTDIR не понимается, make install не делится на make install-data и make install-exec, а ведь мне выгоднее сначала задестдирить экзеки от разных архитектур, чтобы склеить в универсальный бинарник, а уже потом добавить данные от одной архитектуры. Данные ведь всё равно склеивать не надо. Ладно, лишние подробности.

Особенно не понравились пакеты на языках perl и python. У них отсутствует ./configure и этапы make как таковые. Вместо этого там исполняемые файлы setup.py и makefile.pl. Неприятность работать с ними заключается в том, что там всё по–своему. Те пакеты, которые меня интересуют, содержат "вкрапления" на C, и мне не нравится, что, если я чего-то упустил, то система сборки начинает своевольничать. Чтобы этого не было, я сначала собираю ppc архитектуру (а у меня intel). Если система сборки вдруг решает, что она умнее, чем я, то она во многих случаях обссыкается, и я вижу, где это произошло. Если компилеру или линкеру не передать -arch ppc, то они пытаются собрать в родной i386 архитектуре, при этом зависимости собраны по-прежнему в ppc. Если я собираю pygtk, то во время компиляции я настраиваю среду окружения на ppc версию gtk+, а не на универсальную, хотя она уже к этому моменту готова. У меня складывается впечатление, что в сами python и perl вшиты какие-то ключи компиляции, которые, если недосмотреть, могут заменять те, которые хочу использовать я.

В общем, охота, чтоб в одном месте было много инфы о том, как производить сборку разнотипных пакетов. Меня интересует создание unattended инсталляций. И как настраивать среду окружения при этом. Что делать, если нужно использовать python, который стоит в системе и что делать, если нужно использовать тот, который идёт в слепке. Сами по себе слепки не является перемещаемыми, просто ни одна программа из слепка не вызывается снаружи напрямую. Снаружи вызывается обёртка, которая настраивает среду так, что все программы внутри могут нормально работать. На Mac OS X это стандартный способ портировать программы, сделанные на autotools и пр. Вообще, я видел подобные "слепки" и под linux, вспомнить хотя бы GNAT GPL. gps настраивает среду и вызывает gps_exe.

Собственно задача -- прокачать скиллы мейнтейнера, а создание слепков -- это приятное с полезным.

>>>

Nihilist ()

Linux для параноика :)

Переполнения буффера были и остаются частью нашей жизни. Уж сколько раз твердили миру, а мир всё пишет на C/C++.

Так вот, мне интересны техники исключения небезопасностей C++. А именно, переполнения буффера и висячие указатели, хотя бы эти источники ошибок. Меня интересуют компиляторы, виртуальные машины C++ и т. д., в которых выполнить подобную операцию было бы невозможно. В идеале -- пересобрать какой-нибудь популярный дистр этим компилятором. Но это вряд ли, как-то нереально звучит, поэтому топик в Talks. Это было бы полезно не только для безопасности юзера, но и для улучшения кода. Ошибки, которые могут быть не видны при исполнении в обычном режиме, не проскочат в режиме защищённом. Соответственно, можно слать баг-репорты куда надо. Это лучше, чем просто надеяться на авось^Wмиллион пытливых глаз.

Конечно, это падение производительности и другие затраты. Скажем, трёхкратное падение производительности на Core 2 Duo можно позволить. Просто очень хочется.

Nihilist ()

RSS подписка на новые темы