Как собрать программу из исходников linux

Этичная сборка ПО из исходников.

Объясните, пожалуйста, неофиту(т.е. мне) каким способом можно собирать программы из исходного кода не засоряя при этом основную систему? Например, мне захотелось «потыкать палочкой» в проект, который написан 2-х языках программирования и использующий несколько библиотек в зависимостях. Следовательно, все это безобразие в виде libkgb-1.0, NameLang Compiler попадет ко мне в основную систему и после сборки придется вычищать все ненужное руками. Но я уже устал заниматься такой рутиной и следовательно вопрос: существуют ли специальные окружения, позволяющие изолировать директорию проекта от основной системы? Например, создал виртуальное окружение, скачал в него исходный код, скачал необходимые зависимости для сборки, собрал, удалил окружение оставив систему в изначальной чистоте.

eyrell
24.12.22 22:32:10 MSK

• Ответить на это сообщение
• Ссылка

← 1 2 →

hateyoufeel ★★★★★
( 26.12.22 09:44:53 MSK )

• Ответить на это сообщение
• Ссылка

Ответ на: комментарий от soomrack 24.12.22 23:19:36 MSK

Решение с qemu более удобное

lxc удобнее тем, что лучше монтируются директории. А в Qemu для этого два разных протокола (старый 9P и новый) и их непросто настраивать.

Shushundr ★★☆
( 26.12.22 10:05:27 MSK )

• Ответить на это сообщение
• Показать ответ
• Ссылка

Ответ на: комментарий от Jameson 24.12.22 23:15:22 MSK

Тебе просто лень изучать Nix. Поэтому ты цепляешься за Gentoo.

Shushundr ★★☆
( 26.12.22 10:06:21 MSK )

• Ответить на это сообщение
• Показать ответы
• Ссылка

Ответ на: комментарий от Jameson 24.12.22 23:49:56 MSK
Shushundr ★★☆
( 26.12.22 10:07:39 MSK )

• Ответить на это сообщение
• Показать ответ
• Ссылка

vbr ★★★
( 26.12.22 11:03:57 MSK )

• Ответить на это сообщение
• Ссылка

Ответ на: комментарий от rukez 24.12.22 23:27:31 MSK

Что в дебиане что в рхеле пакетные манагеры умеют удалять ровно то что ты поставил т.е. условно если после apt install rust (что притащит 100500 пакетов) сделать apt delete rust то ровно эти же 100500 и будут унесены ветром

Это неправда. Во всех менеджерах есть возможность выполнения скриптов. Когда установленный пакет тебе сделает rm -rf /etc, никакой delete тебе его уже не вернёт.

vbr ★★★
( 26.12.22 11:05:52 MSK )

• Ответить на это сообщение
• Показать ответ
• Ссылка

Ответ на: комментарий от Shushundr 26.12.22 10:06:21 MSK

Nix можно поставить в Gentoo.

hateyoufeel ★★★★★
( 26.12.22 12:26:35 MSK )

• Ответить на это сообщение
• Ссылка

Ответ на: комментарий от Shushundr 26.12.22 10:06:21 MSK

Я пытался, я не осилил, мне стыдно и я каждый год обещаю себе всё таки разобраться. Так как сама философия дистрибутива мне нравится. Но вот у меня сложилось ощущение что для того чтобы им жоско рулить нужно мыслить как программист, стать программистом. А я не программист, мне с конфигурированием было тяжко. Они там свой язык программирования для настройки ОС изобрели, он меня пугает и я не осилил его освоить.

Jameson ★★★★★
( 26.12.22 14:15:14 MSK )
Последнее исправление: Jameson 26.12.22 14:35:28 MSK (всего исправлений: 2)

• Ответить на это сообщение
• Ссылка

Ответ на: комментарий от Shushundr 26.12.22 10:07:39 MSK

Это был сарказм в ответ на сарказм. Я знаю что такая «штука» давно есть, и не одна. В моём случае вместо btrfs lvm2+ext4, меня Эдик Шишкин покусал, ну и личный опыт с btrfs был смешной и неприятный, например удалить инфу с FS для того чтобы освободить место невозможно по причине отсутствия места. Для удаления не хватило места, да. И это не баг, это проистекающая из основ дизайна FS фича. Я конечно подключил флешку, растянул, удалил, сократил, но решил что подожду ка я ещё лет ннадцать, пока меня силой мигрировать не заставят. Ибо lvm2+ext4 по прежнему делает всё то что мне от btrfs нужно.

Jameson ★★★★★
( 26.12.22 14:29:41 MSK )
Последнее исправление: Jameson 26.12.22 14:30:57 MSK (всего исправлений: 1)

• Ответить на это сообщение
• Ссылка

Ответ на: комментарий от vbr 26.12.22 11:05:52 MSK

Это неправда. Во всех менеджерах есть возможность выполнения скриптов. Когда установленный пакет тебе сделает rm -rf /etc, никакой delete тебе его уже не вернёт.

В каждом доме есть нож. Нож воткнутый в голову при выполнении apt install аналогично не выскочит при apt delete
Странные аналогии требуют странных аналогий.
Наличие rm rf в скрипте пакета говорит о том что у кого-то был нож и он искал твою голову — не дружи с такими ребятами и не бери у них пакеты

rukez ★★★★
( 26.12.22 16:16:38 MSK )

• Ответить на это сообщение
• Показать ответ
• Ссылка

Ответ на: комментарий от rukez 26.12.22 16:16:38 MSK

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

vbr ★★★
( 26.12.22 16:23:01 MSK )

• Ответить на это сообщение
• Ссылка

Никогда не надо собирать софт руками, надо всегда делать пакет. Это быстрее, потому что фреймворк половину работы делает за тебя, и несравнимо удобнее потому что сборку всегда можно повторить — сейчас, через год (когда забыл что доставлял и с какими ключами конфигурил), на другой машине, после обновления зависимостей — когда и где угодно, а также гарантируется что сборка не насрёт файлов куда не надо, пакет можно начисто удалить, и, наоборот, его зависимости не удалятся потому что больше никому не нужны, а пакетный менеджер не знает о сборке.

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

Неофиты обычно на это отвечают что им лень учиться писать пакеты, но повторюсь — сборка через пакет всегда лучше, поэтому либо учишь, либо тратишь своё время впустую.

slovazap ★★★★★
( 26.12.22 23:09:49 MSK )

• Ответить на это сообщение
• Ссылка

Сначала сделай из исходников пакет src.rpm, а из него уже собирай rpm пакет. И все будет чисто и аккуратно.

vasya_pupkin ★★★★★
( 27.12.22 00:09:41 MSK )

• Ответить на это сообщение
• Ссылка

Ответ на: комментарий от Shushundr 26.12.22 10:05:27 MSK

lxc удобнее тем, что лучше монтируются директории. А в Qemu для этого два разных протокола (старый 9P и новый) и их непросто настраивать.

Если нужна изоляция, то монтировать как-то не хочется, а если же все же нужно, то sshfs вполне себе хороший вариант.

soomrack ★★★★
( 29.12.22 16:48:23 MSK )

• Ответить на это сообщение
• Показать ответ
• Ссылка

Ответ на: комментарий от soomrack 29.12.22 16:48:23 MSK

какой же он хороший, если вставляет два дополнительных слоя, которые нафиг не нужны? один слой — это шифрование, а второй слой это FUSE

Shushundr ★★☆
( 29.12.22 17:29:36 MSK )

• Ответить на это сообщение
• Показать ответ
• Ссылка

Ответ на: комментарий от Shushundr 29.12.22 17:29:36 MSK

Какая разница сколько слоев, если хорошо работает?

soomrack ★★★★
( 29.12.22 17:33:49 MSK )

• Ответить на это сообщение
• Ссылка

Компиляция и установка программ из исходников

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

Распаковка

Программы обычно распространяются в упакованных архивах, это файлы с расширениями

.tar.gz (иногда .tgz) .tar.bz2

Нужно понимать отличие между архиватором и упаковщиком.

Для архивации директорий и файлов используется программа tar; результатом её работы является файл с расширением .tar. Грубо говоря, это копия файловой системы — директорий и файлов с их атрибутами и правами доступа, помещённая в один файл.

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

Программа tar умеет распаковывать, поэтому не нужно вызывать gunzip, а можно просто указать программе tar, что файл нужно cначала распаковать. Например, команда

tar -xvf some_app_name>.tar.gz

сразу распакует и разархивирует. Отличие файлов с расширениями

.tar.gz

.tar.bz2

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

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

cd имя_пакета>*

Сборка пакета

Для сборки программ в GNU/Linux используется (в основном) программа make, которая запускает инструкции из Makefile, но поскольку дистрибутивов GNU/Linux много, и они все разные, то для того чтобы собрать программу, нужно для каждого дистрибутива отдельно прописывать пути,где какие лежат библиотеки и заголовочные файлы. Программисты не могут изучать каждый дистрибутив и для каждого отдельно создавать Makefile. Поэтому придумали конфигураторы, которые «изучают» систему, и в соответствии с полученными знаниями создают Makefile. Но на конфигураторе они не остановились и придумали конфигураторы конфигураторов …на этом они остановились

Для сборки нам нужны компиляторы: они прописаны в зависимостях пакета build-essential, так что достаточно установить его со всеми зависимостями. Ещё нужны autoconf и automake.

Итак, чтобы собрать что-то из исходников, нужно сначала собрать конфигуратор; как собрать конфигуратор, описано в файле configure.in. Для сборки конфигуратора необходимо выполнить

./bootstrap

./autogen.sh

Если таких скриптов в архиве не оказалось, то можно выполнить последовательно следующие команды:

aclocal autoheader automake --gnu --add-missing --copy --foreign autoconf -f -Wall

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

./configure

Конфигуратор построит Makefile основываясь на полученных знаниях и файле makefile.am. Можно передать конфигуратору опции, предусмотренные в исходниках программы, которые позволяют включать/отключать те или иные возможности программы, обычно узнать о них можно командой

./configure --help

Также есть набор стандартных опций, вроде

--prefix=

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

--prefix=/usr

--prefix=/usr/local

БЕЗ слеша в конце! Теперь можно запустить процесс сборки самой программы командой

make

Для сборки достаточно привелегий обычного пользователя. Окончанием сборки можно считать момент, когда команды в консоли перестанут «беспорядочно» выполняться и не будет слова error. Теперь всё скомпилировано и готово для установки.

Установка

Усилия потраченные на Правильную установку в последствии с лихвой окупятся в случае удаления или обновления устанавливаемого программного обеспечения.

Правильная установка(Вариант №1)

Установка при помощи утилиты checkinstall. Для установки выполните

sudo apt-get install checkinstall

Минус данного способа: checkinstall понимает не все исходники, поскольку автор программы может написать особые скрипты по установке и checkinstall их не поймёт.

Для создания и установки deb-пакета необходимо выполнить

sudo checkinstall

Правильная установка(Вариант №2)

Быстрое создание deb-пакета «вручную».

Основное отличие от предыдущего способа заключается в том, что в данном случае вы создаете пакет вручную и отслеживаете все вносимые изменения. Так же этот способ подойдет вам, если исходники не поддерживают сборку пакета с checkinstall.

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

fakeroot make install DESTDIR=`pwd`/tempinstall

Создадим в «корне пакета» директорию DEBIAN и сложим в DEBIAN/conffiles список всех файлов, которые должны попасть в /etc:

сd tempinstall mkdir DEBIAN find etc | sed "s/^/\//" > DEBIAN/conffiles

После чего создаём файл DEBIAN/control следующего содержания:

Package: имя_пакета Version: 1.2.3 Architecture: amd64/i386/armel/all Maintainer: Можете вписать своё имя, можете дребедень, но если оставить пустым, то dpkg будет ругаться Depends: Тут можно вписать список пакетов через запятую. Priority: optional Description: Тоже надо что-нибудь вписать, чтобы не кидало предупреждения

При необходимости там же можно создать скрипты preinst, postinst, prerm и postrm.
Создаем deb-пакет, для чего выполняем:

dpkg -b tempinstall

Получаем на выходе tempinstall.deb, который и устанавливаем

sudo dpkg -i tempinstall.deb

Подготовка

Для начала нам понадобятся исходники Scan Tailor’а. Их можно скачать с официального сайта или взять из SVN. В SVN лежат самые последние изменения, и он предназначен прежде всего для разработчиков. Если вы решили взять исходники из SVN, предполагается, что вы представляете себе, что это такое. Если так, то вам достаточно знать SVN URL чтобы вы смогли взять исходники оттуда. Итак, SVN URL у нас такой:

• Базовый инструментарий для сборки. В Ubuntu есть мета-пакет build-essential, который тянет за собой все основные коомпоненты, необходимые для сборки программ из исходников.
• Система сборки CMake. Наверняка есть в репозитории вашего дистрибутиве под именем cmake.
• Qt версии по крайней мере 4.4.0. Она есть в достаточно свежих дистрибутивах, по крайней мере тех, где есть KDE 4.1 или выше, потому как KDE 4.1 требует Qt 4.4. Нужны не только сама библиотека Qt, но и заголовочные файлы, которые как правило находятся в пакетах с именами, заканчивающимеся на -dev. Например в Ubuntu нужный нам пакет называется libqt4-dev. Он потянет за собой и саму библиотеку Qt, если она еще не установлена.
• Заголовочные файлы от еще нескольких пакетов, а именно libpng (libpng12-dev), libjpeg (libjpeg62-dev), libtiff (libtiff4-dev), libxrender (libxrender-dev). Последний может также называться libXrender-dev, а раньше он был частью libx11-dev. Все эти пакеты определенно есть в репозитории вашего дистрибутива.

Сборка

Открываем консоль (терминал), идем в директорию, куда распаковали исходники Scan Tailor’а, и даем команду «cmake .» (там точка в конце):

cd "/home/username/путь/к/ST" cmake .

Если все прошло успешно, то ближе к концу вы увидите строки:

-- Configuring done -- Generating done

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

ccmake .

И потом вручную указать пути к тем или иным не найденным файлом. ccmake — консольное интерактивное приложение, так что не помешают некоторые инструкции.

1. Клавишами со стрелками наводим курсор на строкy TIFF_LIBRARY.
2. Enter.
3. Вводим правильный путь.
4. Enter.
5. [Правим таким же образом остальные ненайденные пути].
6. Жмем c
7. Жмем g

Когда CMake наконец отработал успешно, можно приступать к самой сборке:

make

Если сборка завершается с ошибками (не доходит до 100%), задайте вопрос на форуме.

Теперь остается сделать:

sudo make install

На этом этапе вас спросят ваш пароль, так как инсталляция требует прав рута.

На этом сборка и инсталляция закончены, и Scan Tailor готов к запуску. К сожалению, данный процесс инсталляции не предусматривает создания пункта меню, так что вам придется либо создать его самостоятельно, либо запускать его через Alt+F2 набрая там комманду «scantailor» (без кавычек).

Этичная сборка ПО из исходников.

Объясните, пожалуйста, неофиту(т.е. мне) каким способом можно собирать программы из исходного кода не засоряя при этом основную систему? Например, мне захотелось «потыкать палочкой» в проект, который написан 2-х языках программирования и использующий несколько библиотек в зависимостях. Следовательно, все это безобразие в виде libkgb-1.0, NameLang Compiler попадет ко мне в основную систему и после сборки придется вычищать все ненужное руками. Но я уже устал заниматься такой рутиной и следовательно вопрос: существуют ли специальные окружения, позволяющие изолировать директорию проекта от основной системы? Например, создал виртуальное окружение, скачал в него исходный код, скачал необходимые зависимости для сборки, собрал, удалил окружение оставив систему в изначальной чистоте.

eyrell
24.12.22 22:32:10 MSK

• Ответить на это сообщение
• Ссылка

← 1 2 →

Собери все либы сам, слинкуй куда надо и сложи где надо, делов то?

burato ★★★★★
( 24.12.22 22:34:38 MSK )

• Ответить на это сообщение
• Ссылка

Развернуть chroot и сорить там как угодно.

LINUX-ORG-RU ★★★★★
( 24.12.22 22:35:24 MSK )

• Ответить на это сообщение
• Ссылка

Если ты собираешь не из под рута, то систему ты портить не будешь.

Если нужно собирать из под рута (зачем?), то можешь сделать chroot.

Если хочешь большей безопасности и гибкости, то лучше сделать виртуалку в qemu и собирай в ней, тогда сохранив ее первоначальный образ (тупо скопировав файл – ее диск), ты будешь всегда иметь чистую систему. Я поступаю так.

soomrack ★★★★
( 24.12.22 22:36:19 MSK )

• Ответить на это сообщение
• Показать ответ
• Ссылка

Использовать пакетный менеджер, собирающий в песочнице. Желательно такой, в котором вообще нет этой штуки из прошлого века под названием «установка в систему», но в принципе сойдёт и какой-нибудь популярный из прошлого века.

t184256 ★★★★★
( 24.12.22 22:37:12 MSK )

• Ответить на это сообщение
• Показать ответ
• Ссылка

vvn_black ★★★★★
( 24.12.22 22:38:43 MSK )

• Ответить на это сообщение
• Показать ответы
• Ссылка

Ответ на: комментарий от soomrack 24.12.22 22:36:19 MSK

Если ты собираешь не из под рута, то систему ты портить не будешь. систему ты портить не будешь.

Под «портить» я подразумевал установку тулчейна для сборки проекта. Конечно, можно скачивать, линковать и раскладывать по папочкам зависимости вручную, как предлагал выше Бурато, но велик соблазн установить библиотеку/компилятор с помощью пакетного менеджера, а здесь уже установка в систему через sudo.

Например, мне нужно скомпилировать программу на условном Rust, Zig, etc, для этого мне придется устанавливать компилятор этого языка в систему через пакетный менеджер, а после сборки его удалять, верно? Поэтому хотелось бы удалить сразу окружение, а не сидеть вспоминать, что я устанавливал через пакетный менеджер.

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

Похоже, что придется копать в эту сторону, да.

eyrell
( 24.12.22 23:00:19 MSK ) автор топика

• Ответить на это сообщение
• Показать ответы
• Ссылка

Ответ на: комментарий от vvn_black 24.12.22 22:38:43 MSK
eyrell
( 24.12.22 23:02:59 MSK ) автор топика

• Ответить на это сообщение
• Ссылка

Ответ на: комментарий от t184256 24.12.22 22:37:12 MSK

Желательно такой, в котором вообще нет этой штуки из прошлого века под названием «установка в систему»

Это намек на nix/guix?

eyrell
( 24.12.22 23:05:10 MSK ) автор топика

• Ответить на это сообщение
• Показать ответ
• Ссылка

Ответ на: комментарий от eyrell 24.12.22 23:00:19 MSK

Например, мне нужно скомпилировать программу на условном Rust, Zig, etc, для этого мне придется устанавливать компилятор этого языка в систему через пакетный менеджер, а после сборки его удалять, верно? Поэтому хотелось бы удалить сразу окружение, а не сидеть вспоминать, что я устанавливал через пакетный менеджер.

В генту это просто решается. Есть такая штука, set, вручную составляемый список пакетов которые я могу поставить и снести пачкой, оперируя именем созданного сета. Необходимые пакетам зависимости поставятся сами, и сами же снесутся при «чистке» системы после того как я сет удалю. Так что если мне для внутрихомячной ручной сборки требуются некие зависимости, которые я не хочу видеть постоянно в своей системе и после того как наиграюсь возжелаю удалить — я из них сет сформирую, а потом этот сет удалю.

Ну и если я решу что внутрихомячная софтина достойна того чтобы быть — напишу ebuild и положу в персональный домашний оверлей, и софтина станет легальной частью системы. А то что в сете будет вписано мною в ебилд как зависимости, сборочные или постоянные. Надобность в сете после этого отпадёт.

Jameson ★★★★★
( 24.12.22 23:15:22 MSK )
Последнее исправление: Jameson 24.12.22 23:17:14 MSK (всего исправлений: 1)

• Ответить на это сообщение
• Показать ответы
• Ссылка

Ответ на: комментарий от Jameson 24.12.22 23:15:22 MSK

В целом да, но могут возникать случаи, когда установка библиотеки потянет за собой необходимость выставить use-флаги для уже имеющегося софта, или что еще хуже обновить версию до ~amd64.

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

soomrack ★★★★
( 24.12.22 23:19:36 MSK )

• Ответить на это сообщение
• Показать ответы
• Ссылка

Ответ на: комментарий от eyrell 24.12.22 23:00:19 MSK

Docker/podman будет более эпично, чем виртуалка. Есть официальные docker образы для rust, zig, да и практически для всего, что только можно.

rupert ★★★★★
( 24.12.22 23:23:00 MSK )

• Ответить на это сообщение
• Ссылка

Что в дебиане что в рхеле пакетные манагеры умеют удалять ровно то что ты поставил т.е. условно если после apt install rust (что притащит 100500 пакетов) сделать apt delete rust то ровно эти же 100500 и будут унесены ветром

Однако (с) я тоже держу виртуалку у которой после установки чистой ос тупо скопирован файл диска 🙂
Один из плюсов — в виртуалке у тебя образуется готовое окружение под конкретную задачу, которое формирует определённый результат — для его повторения достаточно не трогать виртуалку между подходами — у меня так даже пара репок гита заморожены «тупо на всякий случай». При этом ее можно спокойно переносить между машинами (ежли, допустим, ты работаешь на ноуте и у тебя есть могучий вычислитель под кроватью то можно все спихнуть на него)

rukez ★★★★
( 24.12.22 23:27:31 MSK )

• Ответить на это сообщение
• Показать ответы
• Ссылка

Ответ на: комментарий от soomrack 24.12.22 23:19:36 MSK

Да, наверное, но как то заморочено как по мне. Да и qemu я к стыду своему плохо осиливаю, мне как то виртуалбокса всегда хватало, в нём быстро, мышкой натыкал и виртуалку запустил. А в qemu меня угнетает портянка параметров запуска и кривые полурабочие графические морды, которых при этом много разных, из за которых всё равно упарываешься в рукопашную портянку параметров в итоге. И да, я знаю что qemu/kvm круче, а я ленивый ламер.

А так если юзы нужно поменять чему то уже установленному, так конфиги портажа модульные и комментарии поддерживают. Поменял этому чему то юз индивидуально, создал специальный файл под это в /etc/portage/package.use/ и подробно в нём прокомментировал, что это и зачем было нужно.

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

Jameson ★★★★★
( 24.12.22 23:27:57 MSK )
Последнее исправление: Jameson 24.12.22 23:36:11 MSK (всего исправлений: 1)

• Ответить на это сообщение
• Показать ответ
• Ссылка