Как собрать приложение из исходников

советы

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

Сейчас такая ситуация случается гораздо реже, благо установка и обновление программ в Debian больше напоминает заказ в ресторане: хочу это, хочу то — подождите — готово! Однако умение собирать программы из исходников рано или поздно пригождается практически любому пользователю свободного программного обеспечения. И сложного в этом ничего нет.

Достаточно один раз в жизни услышать волшебное заклинание: » configure , make , make install «. Дальше я объясню, что это значит.

Сборку программы можно сравнить с выпечкой пирога. Чаще всего, вначале надо взять все необходимые ингридиенты (исходники),
потом смешать их в нужном порядке (подготовить исходники к сборке, ./configure ), а затем залить в форму и поставить в печь (запустить сборку, make ). Спустя некоторое время из печи можно вынимать готовый к употреблению пирог (устанавливать готовую программу, make install ).

Следует отметить, что в данном случае для выпечки необходима кухня и печь. Также и для сборки программы необходимы инструменты разработчика. Обычно это включает в себя как минимум компилятор и сопутствующие ему программы, как например утилита make . Это и есть «печь». Потребуется и место, где можно всем этим заняться — командная строка (терминал) («кухня»). Если у вас есть и кухня, и печь, то можете начинать готовить.

Итак, все свободные программы доступны в виде исходного кода. Это полуфабрикат программы. Из него легко можно собрать саму программу, а можно и использовать для создания какой-нибудь новой программы. По-английски исходный код называется source code.

Шаг 1: берём исходники

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

Распаковать архив можно так:

(Не забывайте, что в большинстве случае нажатие клавиши Tab позволяет дополнить имя файла, введя лишь несколько первых символов). При этом содержимое архива будет распаковано в тот же каталог, в котором находится архив.

Перейдите в каталог с исходным кодом:

Шаг 2: configure (месим тесто)

Прочитайте файлы INSTALL и README , если они есть в архиве исходного кода. В них может содержаться важная информация о том, как устанавливать и использовать программу.

В большинстве случае для подготовки исходников к сборке потребуется выполнить только одну команду:

Она проверит наличие всех необходимых условий (библиотек и других программ) в Вашей системе, и приготовит исходный код к их использованию. Обратите внимание на символы » ./ » в начале команды. Они указывают, что необходимо выполнить команду configure из текущего каталога, то есть команду configure поставляемую вместе с исходным текстом программы, которую мы собираем.

На этом же этапе можно указать и куда именно надо ставить программу. Хотя в большинстве случаев рекомендуется ставить «самосборные» программы в каталог /usr/local , иногда это невозможно. Так, если у пользователя нет прав администратора, например на общественном компьютере, то установить программу можно только в свой домашний каталог. Чтобы установить программу в домашний каталог нужно указать дополнительный параметр команде configure :

Внимательно читайте что пишется на экране при подготовке исходников. Если всё нормально, то закончится она должна чем-нибудь вроде

Если же появляются какие-то сообщения об ошибках, значит чего-то на вашей «кухне» для приготовления этой программы видимо не хватает. Чаще всего какой-нибудь библиотеки. Какой — подскажет вывод программы configure

Шаг 3: make (в печь!)

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

Для больших программ этот процесс может занимать довольно много времени. Однако наша программа-пример hello должна собраться быстро.

Если сборка закончилась сообщением вроде этого:

то значит, что-то пошло не так, и сборка не получилась. Однако чаще всего сборка заканчивается без ошибок.

Шаг 4: make install (кушать подано!)

Собственно всё. Пирог можно подавать к столу, а собранную программу устанавливать в систему. Делается это так:

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

/bin в переменную PATH :

Можете запускать собранную программу:

Она пишет на экран «Здравствуй, мир!». Всё ОК.

Надеюсь, что эти инструкции будут понятны даже совсем начинающим пользователям линукс. Мне в своё время не хватало таких инструкций 🙂

P.S. Хочу, однако, заметить, что сборка из исходников несёт с собой целый ряд неудобств. Первое и наиболее существенное из них — удалять такую программу гораздо хлопотнее. В случае с hello это можно сделать с помощью команды

в каталоге с её исходным кодом, но не всегда этот каталог сохраняется в целостности, да и не все авторы программ должным образом готовят исходные тексты к make uninstall

Поэтому лучше пользоваться готовыми пакетами, поставляемые с Вашим дистрибутивом. Так, чтобы установить программу hello в Debian GNU/Linux достаточно всего одной команды:

Просто о make

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

Мое упорное игнорирование make в течении долгого времени, было обусловлено удобством используемых IDE, и нежеланием разбираться в этом ‘пережитке прошлого’ (по сути — ленью). Однако, все эти надоедливые кнопочки, менюшки ит.п. атрибуты всевозможных студий, заставили меня искать альтернативу тому методу работы, который я практиковал до сих пор. Нет, я не стал гуру make, но полученных мною знаний вполне достаточно для моих небольших проектов. Данная статья предназначена для тех, кто так же как и я еще совсем недавно, желают вырваться из уютного оконного рабства в аскетичный, но свободный мир шелла.

Make- основные сведения

make — утилита предназначенная для автоматизации преобразования файлов из одной формы в другую. Правила преобразования задаются в скрипте с именем Makefile, который должен находиться в корне рабочей директории проекта. Сам скрипт состоит из набора правил, которые в свою очередь описываются:

1) целями (то, что данное правило делает);
2) реквизитами (то, что необходимо для выполнения правила и получения целей);
3) командами (выполняющими данные преобразования).

В общем виде синтаксис makefile можно представить так:

То есть, правило make это ответы на три вопроса:

Несложно заметить что процессы трансляции и компиляции очень красиво ложатся на эту схему:

Простейший Makefile

Предположим, у нас имеется программа, состоящая всего из одного файла:

Для его компиляции достаточно очень простого мэйкфайла:

Данный Makefile состоит из одного правила, которое в свою очередь состоит из цели — «hello», реквизита — «main.c», и команды — «gcc -o hello main.c». Теперь, для компиляции достаточно дать команду make в рабочем каталоге. По умолчанию make станет выполнять самое первое правило, если цель выполнения не была явно указана при вызове:

Компиляция из множества исходников

Предположим, что у нас имеется программа, состоящая из 2 файлов:
main.c

Makefile, выполняющий компиляцию этой программы может выглядеть так:

Он вполне работоспособен, однако имеет один значительный недостаток: какой — раскроем далее.

Инкрементная компиляция

Представим, что наша программа состоит из десятка- другого исходных файлов. Мы вносим изменения в один из них, и хотим ее пересобрать. Использование подхода описанного в предыдущем примере приведет к тому, что все без исключения исходные файлы будут снова скомпилированы, что негативно скажется на времени перекомпиляции. Решение — разделить компиляцию на два этапа: этап трансляции и этап линковки.

Теперь, после изменения одного из исходных файлов, достаточно произвести его трансляцию и линковку всех объектных файлов. При этом мы пропускаем этап трансляции не затронутых изменениями реквизитов, что сокращает время компиляции в целом. Такой подход называется инкрементной компиляцией. Для ее поддержки make сопоставляет время изменения целей и их реквизитов (используя данные файловой системы), благодаря чему самостоятельно решает какие правила следует выполнить, а какие можно просто проигнорировать:

Попробуйте собрать этот проект. Для его сборки необходимо явно указать цель, т.е. дать команду make hello.
После- измените любой из исходных файлов и соберите его снова. Обратите внимание на то, что во время второй компиляции, транслироваться будет только измененный файл.

После запуска make попытается сразу получить цель hello, но для ее создания необходимы файлы main.o и hello.o, которых пока еще нет. Поэтому выполнение правила будет отложено и make станет искать правила, описывающие получение недостающих реквизитов. Как только все реквизиты будут получены, make вернется к выполнению отложенной цели. Отсюда следует, что make выполняет правила рекурсивно.

Фиктивные цели

На самом деле, в качестве make целей могут выступать не только реальные файлы. Все, кому приходилось собирать программы из исходных кодов должны быть знакомы с двумя стандартными в мире UNIX командами:

Командой make производят компиляцию программы, командой make install — установку. Такой подход весьма удобен, поскольку все необходимое для сборки и развертывания приложения в целевой системе включено в один файл (забудем на время о скрипте configure). Обратите внимание на то, что в первом случае мы не указываем цель, а во втором целью является вовсе не создание файла install, а процесс установки приложения в систему. Проделывать такие фокусы нам позволяют так называемые фиктивные (phony) цели. Вот краткий список стандартных целей:

all — является стандартной целью по умолчанию. При вызове make ее можно явно не указывать.
clean — очистить каталог от всех файлов полученных в результате компиляции.
install — произвести инсталляцию
uninstall — и деинсталляцию соответственно.

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

Обратите внимание на то, что в цели all не указаны команды; все что ей нужно — получить реквизит hello. Зная о рекурсивной природе make, не сложно предположить как будет работать этот скрипт. Так же следует обратить особое внимание на то, что если файл hello уже имеется (остался после предыдущей компиляции) и его реквизиты не были изменены, то команда make ничего не станет пересобирать. Это классические грабли make. Так например, изменив заголовочный файл, случайно не включенный в список реквизитов, можно получить долгие часы головной боли. Поэтому, чтобы гарантированно полностью пересобрать проект, нужно предварительно очистить рабочий каталог:

Для выполнения целей install/uninstall вам потребуются использовать sudo.

Переменные

Все те, кто знакомы с правилом DRY (Don’t repeat yourself), наверняка уже заметили неладное, а именно — наш Makefile содержит большое число повторяющихся фрагментов, что может привести к путанице при последующих попытках его расширить или изменить. В императивных языках для этих целей у нас имеются переменные и константы; make тоже располагает подобными средствами. Переменные в make представляют собой именованные строки и определяются очень просто:

Существует негласное правило, согласно которому следует именовать переменные в верхнем регистре, например:

Так мы определили список исходных файлов. Для использования значения переменной ее следует разименовать при помощи конструкции $(<VAR_NAME>); например так:

Ниже представлен мэйкфайл, использующий две переменные: TARGET — для определения имени целевой программы и PREFIX — для определения пути установки программы в систему.

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

Автоматические переменные

Автоматические переменные предназначены для упрощения мейкфайлов, но на мой взгляд негативно сказываются на их читабельности. Как бы то ни было, я приведу здесь несколько наиболее часто используемых переменных, а что с ними делать (и делать ли вообще) решать вам:

$@ Имя цели обрабатываемого правила
$< Имя первой зависимости обрабатываемого правила
$^ Список всех зависимостей обрабатываемого правила

Заключение

В этой статье я попытался подробно объяснить основы написания и работы мэйкфайлов. Надеюсь, что она поможет вам приобрести понимание сути make и в кратчайшие сроки освоить этот провереный временем инструмент.

Собираем программы из исходников(.tar.gz)

Сборку программы можно сравнить с выпечкой пирога. Чаще всего, вначале надо взять все необходимые ингридиенты (исходники),потом смешать их в нужном порядке (подготовить исходники к сборке, ./configure), а затем залить в форму и поставить в печь (запустить сборку, make). Спустя некоторое время из печи можно вынимать готовый к употреблению пирог (устанавливать готовую программу, make install).

Следует отметить, что в данном случае для выпечки необходима кухня и печь. Также и для сборки программы необходимы инструменты разработчика. Обычно это включает в себя как минимум компилятор и сопутствующие ему программы, как например утилита make. Это и есть «печь». Потребуется и место, где можно всем этим заняться — командная строка (терминал) («кухня»). Если у вас есть и кухня, и печь, то можете начинать готовить.

Итак, все свободные программы доступны в виде исходного кода. Это полуфабрикат программы. Из него легко можно собрать саму программу, а можно и использовать для создания какой-нибудь новой программы. По-английски исходный код называется source code.

Шаг 1: берём исходники

Распаковать архив можно так:
tar zxvf hello-2.1.1.tar.gz

Перейдите в каталог с исходным кодом:
cd hello-2.1.1

Шаг 2: configure (месим тесто)

Прочитайте файлы INSTALL и README, если они есть в архиве исходного кода. В них может содержаться важная информация о том, как устанавливать и использовать программу.

В большинстве случае для подготовки исходников к сборке потребуется выполнить только одну команду:
hello-2.1.1$ ./configure

Она проверит наличие всех необходимых условий (библиотек и других программ) в Вашей системе, и приготовит исходный код к их использованию. Обратите внимание на символы «./» в начале команды. Они указывают, что необходимо выполнить команду configure из текущего каталога, то есть команду configure поставляемую вместе с исходным текстом программы, которую мы собираем.

На этом же этапе можно указать и куда именно надо ставить программу. Хотя в большинстве случаев рекомендуется ставить «самосборные» программы в каталог /usr/local, иногда это невозможно. Так, если у пользователя нет прав администратора, например на общественном компьютере, то установить программу можно только в свой домашний каталог. Чтобы установить программу в домашний каталог нужно указать дополнительный параметр команде configure:
hello-2.1.1$ ./configure —prefix=$HOME

Внимательно читайте что пишется на экране при подготовке исходников. Если всё нормально, то закончится она должна чем-нибудь вроде
config.status: creating Makefile
config.status: creating contrib/Makefile
config.status: creating doc/Makefile
config.status: creating intl/Makefile

Шаг 3: make (в печь!)

Если сборка закончилась сообщением вроде этого:

make: *** [all] Ошибка 2

то значит, что-то пошло не так, и сборка не получилась. Однако чаще всего сборка заканчивается без ошибок.

Шаг 4: make install (кушать подано!)

hello-2.1.1$ make install

/bin в переменную PATH:

Можете запускать собранную программу:

Она пишет на экран «Здравствуй, мир!«. Всё ОК.

Читать:

Какого блока нет в модели разработки игры

hello-2.1.1$ make uninstall

Name already in use

lor / dump / Сборка-программ.wiki

Go to file T
Go to line L
Copy path
Copy permalink

Open with Desktop
View raw
Copy raw contents Copy raw contents

Copy raw contents

Table of Contents

Зачем мне (не)нужно собирать программу из исходников ?

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

Как собрать программу из исходников? Как установить программу из tar.gz/tar.bz2?

Скорее всего в tar.gz/tar.bz2 лежит не программа, а ее исходники. Прежде чем ее поставить, необходимо ее собрать. Для этого нужно выполнить (не бросайтесь сразу это делать):

Поскольку при таком способе установки информация о том, что ставилось и куда, остается только в памяти админа (которая частенько еще какая временная :), лучше для контроля этого процесса использовать checkinstall или похожие программы (почему выше и мы говорили не выполнять команды сразу). После того, как вы, прочитав документацию, установите ее и настроите конфиг, на этапе установки программного обеспечения вместо make install будете писать checkinstall. Checkinstall соберет «настоящий» пакет для указанной (tgz, rpm и deb в зависимости от настроек), установит его в систему и поместит в указанный в конфигурационном файле каталог (удобно для централизованного обновления нескольких машин). Удаление установленных таким образом программ осуществляется стандартными средствами дистрибутива, например, removepkg для Slackware или dpkg для Debian/Ubuntu.

В rpm-based дистрибутивах собирайте программы из srpm или с использованием spec-файлов (для создания rpm). Не превращайте свою систему в помойку. В Slackware программы легко и непринуждённо собираются с помощью простого скрипта SlackBuild. Да и в потомках Debian’a тоже есть штатная система сборки программ в дистрибутивные пакеты и лучше пользоваться ей.

Как удалить программу, собранную из исходников?

Это неоднозначный вопрос. Дело в том, что если вы просто собрали программу с помощью ./configure && make && make install, то все зависит лишь от того, позаботился ли автор об удалении.

Для того, чтобы удалить программу, нужно зайти в каталог ее исходников, из которого она собиралась, и сделать make uninstall. Если каталог не сохранился, распакуйте исходники, запустите ./configure с теми же параметрами, с которыми собирали программу, и выполните make uninstall. А чтобы не полагаться на приличия автора, рекомендуется посмотреть предыдущий вопрос.

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

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

Можно собрать программу без отладочной информации, указав соответствующий ключ — ./configure —disable-debug

Удалить секции с отладочной информацией из уже собранной программы можно командой strip progfile. Посмотреть, что вышло можно командой file progfile, она напишет — stripped или not stripped.

А можно сделать более правильно:

Что прописать в настройках rpm, чтобы для всех собираемых программ выполнялся strip?

Создаем файл /etc/rpm/macros с таким содержанием:

В будущем при смене версии rpm, не придется ничего править в самих макросах из rpm.

Что делать если configure говорит, что XXX не установлен, а на самом деле он установлен?

Для сборки нужны заголовочные файлы (headers). Во многих дистрибутивах библиотеки и программы поделены на два пакета — foo и foo-devel (Fedora, Mandriva) или foo-dev (Debian, Ubuntu). Соответственно нужно поставить foo-devel (foo-dev). Иногда надо вручную запустить ldconfig чтобы увиделись свежеустановленные библиотеки.

Примечание: в пакетах Slackware почти всё вместе.

Я поставил пакет XXX-dev/XXX-devel, а configure все равно говорит, что XXX не установлен

Бывает так, что configure находит пакет XXX, но при попытке использовать файлы из него (в частности, собрать тестовую программу с заголовочными файлами из пакета) происходит какая-нибудь ошибка. configure не может точно определить, что происходит, и считает, что пакет просто не установлен.

Вам нужно искать информацию о происходящей ошибке в файле config.log. Скорее всего, будут какие-то сообщения об ошибках компилятора при сборке тестовых программ.

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

Как собрать rpm пакет из src.rpm (srpm)?

В зависимости от дистрибутива rpm —rebuild название_пакета.src.rpm или rpmbuild —rebuild название_пакета.src.rpm

Кроме того ALT’овцы рекомендуется не собирать пакеты на работающей системе, а использовать hasher

Если вместо ожидаемого результата, на экран выводится список параметров командной строки, нужно установить rpm-devel. Ну а если все получилось, то пакеты будут лежать в /usr/src/название_дистрибутива/BUILD/название_архитектуры_процессора, например /usr/src/redhat/BUILD/i386.

Помогите собрать ядро

— русское пошаговое описание для новичков — архив параметров ядра, разница между разными версиями

Как собрать ядро из src.rpm? Как собрать собственное ядро из src.rpm?

Поскольку у меня (jackill) Fedora, то рассматривать мы будем именно ядра этого дистрибутива. Для других дистрибутивов чуть-чуть будут отличаться пути в /usr/src и, возможно, названия spec-файлов.

Самый простой случай

Мы скачали пакет вида kernel-2.x.x-1.xxx.src.rpm. Нас устраивает конфигурация по умолчанию, но не устраивает сборка под i386. Поэтому пишем:

и забираем готовый пакет из /usr/src/redhat/RPMS/i686

Собираем собственное ядро

Далее перейдем в каталог /usr/src/redhat/SPECS и распакуем сами исходники, наложив при этом все патчи: Теперь переходим в каталог /usr/src/redhat/BUILD/kernel-2.x/linux-2.6, это исходники ядра с соответствующим конфигом. Здесь выполним две команды: Теперь мы можем выставить желаемые параметры. В качестве помощи можете воспользоваться этим разделом. Я обычно включаю поддержку NTFS, выбираю свой тип процессора, убираю поддержку 4ГБ памяти, ставлю соответствующие параметры для samba, а если машина в домене MS Windows 2003, то добавляю поддержку CIFS, а лишнее убиваю.

После того, как вы закончили выставлять параметры, мы переименовываем наш файл конфигурации .config, например в kernel-2.6.8-i686.config и переписываем в каталог /usr/src/redhat/SOURCES.

Далее в kernel-2.x.spec выставляем какое нам нужно собрать ядро (обычное или smp), нужно ли собирать пакет с исходниками и пакет с документацией:

После делаем как обычно.

Если нужно добавить патч

Накладываем этот патч на распакованные исходники, конфигурируем ядро, переписываем так же получившийся конфиг, затем прописываем патч в kernel.spec (в двух местах: в одном сам патч, например Patch10002: vesafb-tng-0.9-rc4-r3-2.6.9-rc3.patch, во втором способ его наложения, например, Patch10002 -p1 — все увидите и сделаете по аналогии).

Если после этого на сборке ядро вылетает, придется сделать make oldconfig для всех файлов конфигурации (повод научиться писать скрипты ;), или убить все конфиги, кроме нужного вам, после чего повторить сборку.

Правда все просто?

Как накладывать патчи? Как накладывать патчи на ядро? (patch, diff)? Как убирать патчи?

Вообще было бы неплохо просто сделать man patch и все стало бы ясно (кстати, сделайте). А как накладывать патчи на ядро написано в самом README к ядру. Тем не менее.

p1 — уровень. Т.е. я захожу в каталог, где непосредственно находятся нужные мне файлы, копирую туда патч и оттуда запускаю эту команду. p0 — нулевой уровень вложенности

Сжатый патч. Это патчи вида mypatch.gz и mypatch.bz2, соответственно:

Чтобы откатить патч, нужно добавить в команду ключик -R

Или можно проще

Нужно ли накладывать промежуточные патчи на ядро?

Есть ядро версии 2.6.6. Нужно получить ядро 2.6.9. Нужно ли накладывать ли patch-2.6.7 и patch-2.6.8? Нужно.

Есть ядро версии 2.6.17.3. Нужно получить ядро 2.6.17.5. Надо откатится обратно до 2.6.17 (patch -p1 -R) и наложить патч до 2.6.17.5

При сборке ядра make menuconfig ругается, что ncurses не установлен.

Установите ncurses-devel или как он там называется в вашем дистрибутиве.

Зачем собирать модули? Почему бы не сделать монолит?

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

У модулей, однако, есть преимущество. Модулю можно передать параметры. Яркий пример — модуль bttv. В случае монолитного ядра параметр придется передавать через загрузчик. Модули так же можно выгружать.

Как правильно собрать Gnome из исходников?

Можно использовать jhbuild, для старых версий garnome.

Как собрать KDE из исходников?

В первую очередь убедитесь что у Вас установлены достаточно новые версии пакетов Qt , soprano, akonadi, boost , также могут потребоваться (для плазмоидов) Google Gadgets, для графического пакета потребуется exiv2, для pim (почтовый клиент, адресная книга и.т.п) — gpg, gpgme,

Большую часть исходников для предзависимостей КДЕ (KDE4) можно скачать с SVN командой

Также Вам потребуется cmake

Порядок сборки — kdelibs , kdepimlibs , kdebase-runtime , kdebase-workspace , все остальные пакеты можно собирать в произвольном порядке.

собирается достаточно тривиально:

распаковываем пакет

создаем папку для сборки внутри распакованой папки

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

команда cmake в отличие от ./configure воспринимает параметры в виде -DCMAKE_INSTALL_PREFIX=/usr (например вместо —prefix=/usr), можно также воспользоваться ccmake или cmake-gui

дальше обычная сборка (-j2 — использовать два потока сборки, для четырехъядерных процессоров можно задавать -j4 и так далее)

после чего можно установить собраные программы с помощью

make install или make install DESTDIR=/путь/установки для последующего создания пакета

Что делать если программа не имеет скрипта configure?

Часто бывает так, что исходный код, загруженный из систем контроля версий не содержит скрипта configure. Иногда его нет и в обычных тарболлах, но есть autogen.sh. Запускаем сначала его, а потом при необходимости — ./configure. Если же отсутствует и он, но есть файлы configure.ac, Makefile.am, Makefile.in., то можно сделать так — autoreconf -v —install

Возможно, что программа использует другую систему сборки, например, scons или qmake (в случае qmake в исходниках будут присутствовать файлы .pro). Если используется cmake , то присутствует CMakeLists.txt и конфигурирование осуществляется командой cmake . (путь к исходникам обязателен, в случае если Вы собираете в корне распакованых исходников текущий путь указывается просто точкой, впрочем, некоторые программы Вам это сделать не дадут и попросят создать отдельный каталог.)

Читайте документацию, она рулит, скорее всего всё, что нужно, написано в README.

Я не успеваю прочитать все сообщения на экране. Похоже там какие-то ошибки

Во время компиляции или запуска различных команд на экране быстро появляется множество различных сообщений, ошибок. Их трудно, почти невозможно прочитать, сохранить.

Для решения этой проблемы воспользуйтесь командой «script».

В текущем каталоге появится файл typescript. Он будет содержать все сообщения которые появлялись на экране. Также можно использовать программу tee.

Как запустить, протестировать, посмотреть программу до установки ее в систему ?

Данное решение работает для множества программ, но не для всех.

Программу можно установить в каталог $HOME/usr. Для этого вместо команды «make install» воспользуйтесь командой

Далее нужно изменить файл $HOME/.bash_profile добавив в него эти строки :

После этого вам нужно перелогиниться в систему.

Будет доступен вызов программ, программы смогут найти свои библиотеки, можно будет вызывать их страницы man, info.

Как запустить программу не устанавливая её, сразу же после компиляции ?

Если программа при запуске требует библиотеки из других каталогов, то для этого скомпилированный elf-файл программы и её библиотеки положите в один каталог.

В этой папке создайте такой файл для запуска программы :

Что такое сборка с обратной связью (FDO/PGO/LWP) ?

Современные компиляторы (GCC => 4.3 или Intel C/C++) позволяют использовать автоматическое профилирование (в отличие от ручного (с помощью gprof, например) поиска наиболее интенсивно нагружающих процессор функций и их переписывания более оптимальным образом), такая оптимизация называется оптимизацией с обратной связью (feedback directed optimization — FDO), легковесным профилированием (LWP — lightweight profiling, в отличие от «тяжеловесного» с помощью gprof и переписывания кода), оптимизацией ведомой профилем (PGO — profile guided optimization). Процедура состоит из 3 фаз, одна из которых может являться интерактивной, т.е. требующей действий от пользователя.

Этап 1: Сборка инструментированных бинарных файлов

Используются ключи компилятора -fprofile-gen (GCC) или -prof-gen (ICC) , целевые бинарные файлы будут содержать много служебного кода, который будет использоваться для сбора статистики во время выполнения программы, инструментированные бинарные файлы имеют низкую производительность сгенерированного кода.

Этап 2: Интерактивная фаза сбора статистики

Программа устанавливается обычным образом (или в отдельный префикс) и используется пользователем, во время работы программы собирается статистика промахов в кеш процессора, использования или неиспользования функций, переменных и так далее. В эту фазу важно постараться использовать программу максимальным образом, например и кодирование и декодирование разных форматов в случае с медиа кодеками, компрессию и декомпрессию с разными опцииями в случае архиваторов, использовать все пункты в меню и открыть все типы документов в случае программы с графическим интерфейсом, для неиспользованных функций информация по профилю собрана не будет. Файлы статистики обычно пишутся в каталог с файлами исходного кода или можно (например для Gentoo portage, при использовании стандартых ebuild’ов) задавать каталог с помощью ключей -fprofile-dir=путь (GCC) или -prof-dir путь (для ICC) на первом этапе.

Этап 3: Пересборка программы с учетом собранной статистики

Производится очистка собраных объектных файлов и пересборка с использованием собраной статистики, используются ключи компилятора -fprofile-use (GCC) или -prof-use (ICC), результирующие бинарные файлы обычно имеют максимально достигаемую с помощью опций компилятора оптимизацию под процессор. В случае с Mozilla Firefox 3.6 оптимизация сборкой под процессор Intel Pentium IV повышает производительность в тестах Peacekeeper на 10%, в случае использования FDO получаем еще 10%, т.е. суммарное ускорение по тестам достигает 20%, неплохой результат не так ли?

Что говорит против использования FDO для сборки программ ?

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

GCC достаточно плохо реагирует на коллизии в статистике возникающие при многопоточности (или просто нескольких одновременных запусках) программы.

И наконец, какой ужас! Собранные бинарные файлы будут привязаны к типу процессора (конвееру, размеру кешей, конкретным ключам сборки, например -mfpmath=sse) , что может проявиться снижением производительности на других процессорах, особенно с меньшим кешем, типом конвеера (in order execution на Intel Atom например), что существенно ограничивает распространение собранных данным методом программ.

Многие алгоритмы уже были отпрофилированы авторами кода вручную, и некоторые даже переписаны на язык assembler, поэтому не удивляйтесь , если потратив уйму времени на профилирование вашего любимого медиа-кодека вы получите прирост менее 1% .

Какие пакеты поддерживают легкую сборку с профилированием?

Mozilla Firefox (make profiledbuild), существует также PKGBUILD для Arch Linux и (в багзилле) ebuild для Gentoo

x264 (make fprofiled VIDS=»список файлов») интерактивная фаза тут не требует вмешательства пользователя,кодек будет отпрофилирован на указанных пользователем файлах с использованием различных настроек кодирования и декодирования.

GCC (make profiledbootstrap) в процессе сборки GCC будет собран backend компилирующий код на C на 7% быстрее , чем без профилирования (для ветки 4.5 пока не работает)

Другие пакеты вам придется собирать по описанной выше трехэтапной схеме, вручную меняя CFLAGS, CXXFLAGS

Как на 64-битной ОС собирать для 32-битной ?

Обмануть автоматическое определение архитектуры помогает утилита setarch, вызвать ее можно как i386 для установления 32-битности ОС. После вызова нужно заново задать переменные окружения, не забудьте и про добавление -m32 в флаги компилятора , а также другие значения, например —libdir=/usr/lib32 для ./configure (если ваша система содержит 32 битные библиотеки в /lib32)