DobrijZmej 08.06.2010 18:10
Переводы — Сборка программ в Linux из исходников.
Озаботил меня как-то вопрос установки ПО в linux.В принципе, большинство ПО можно взять в репозитариях той или иной операционной системы, но иногда мы встречаем на сайте программу в виде tar.gz или tar.bz2 файлов.
Меня, как новичка, до сих пор раздражает процесс установки данных файлов. Немного пролить свет на этот процесс позволила статья Installing software from source in Linux - 1.2. Но беда - она вся на английском языке. Перевода статьи не нашел, но тема достаточно простая, и я взял в руки гугл и начал переводить.
Ниже, собственно, результат моих потуг, а именно мануал по сборке ПО из исходников. Думаю, статья может еще кому-нибудь пригодиться. За все представленные замечания и предложения, а также здоровую критику, заранее спасибо =)
Если нельзя, но очень хочется...
Установка нижеописанным способом имеет один минус:
- установленная программа не появиться в списке установленных пакетов (например в Synaptic). Поэтому начинающим пользователям рекомендую делать процедуру по этой инструкции: Как использовать checkinstall
Ну, а кому интересен сам принцип компиляции исходников и установки программ из них, тех прошу пожаловать ниже =)
Инсталляция программ в Linux.
Итак, Вы загрузили пакет программного обеспечения в виде файла с разрешением tar.gz или tar.bz2, и хотите узнать, что с ним нужно делать. Возможно, Вы уже знаете, что это, скорее всего, исходный код программы, котрую Вы хотите установить, и Вы должны скомпилировать его, но не знаете как это делается. Не волнуйтесь, компиляция и установка программного обеспечения из исходников в Linux это не так сложно, как может показаться.
Процедуры.
Процедура установки программного обеспечения, из пакетов tar.gz или tar.bz2 обычно (но не всегда) происходит так:
1 |
|
Шаг1. Распаковка.
Может быть, Вы уже заметили, что пакеты, содержащие исходные коды программ имеют расширения tar.gz и tar.bz2. Это означает, что пакет представляет собой сжатый tar архив. При оформлении пакета файлы исходного кода другие необходимые файлы были сложены вместе в единый tar-архив, естественно, с расширением tar. После укладки их всех вместе в архив, он был сжат компрессором gzip, и получил, как следствие, расширение gz.
Некоторые люди используют вместо компрессора gzip компрессор bzip2, и в этих случаях файл с программой будет иметь расширение tar.bz2. Эти пакеты распаковываются точно так-же, как tar.gz, только нужно немного изменить командную строку при распаковке. Не имеет значения, куда Вы сохраняете архивы, загруженные из интернета, но я предлагаю создать для них специальный каталог, к примеру dls. Учтите, что каталог dls всего лишь пример. Вы можете разместить загруженные пакеты программ в той папке, в которой захотите. К примеру, предположим, что Ваше имя пользователя me, а пакет, который Вы сохранили в папке dls, созданной в домашнем каталоге (/home/me/dls), называется pkg.tar.gz.
И, наконец, перейдем к распаковке архива. После загрузки пакета распакуйте его следующей командой:
1 |
|
Как Вы видите, для распаковки архива можно использовать команду tar с соответствующими опциями (xvzf). Если Ваш пакет с расширением tar.bz2, то необходимо в параметрах указать, что это более сжатый tar-архив. Это делается с помощью опции z, например так:
1 |
|
Кратко об опциях:
-x = извлечь
-v = подробный режим. Показывает какие файлы распаковываются.
-z = указать, что используется gzip.
-j = указать, что используется bzip2.
-f = указать, с каким файлом работать. Требует после себя аргумента.
Что-же происходит после распаковки, зависит от пакета, но в большинстве случаев будет создан каталог с именем пакета. Только что созданный каталог будет находиться в директории, в которой Вы сейчас находитесь. Естественно, Вы можете просмотреть его командой ls:
1 |
|
В нашем примере получили то, что ожидалось, и архиватор создал из пакета pkg.tar.gz каталог с его именем. Теперь необходимо перейти внутрь этого каталога командой cd:
1 |
|
В данном каталоге может содержаться различная документация, например файлы README или INSTALL. Крайне рекомендую ознакомиться с их содержанием перед продолжением.
Шаг 2. Настройка.
Теперь, после того как мы изменили месторасположение исходников программы (и провели небольшое изучение документации), пришло время конфигурирования пакета. Обычно, но не всегда (именно поэтому необходимо читать файлы REAMDE и INSTALL), это делается запуском конфигурационного скрипта.
Вы можете запустить этот скрипт командой:
1 |
|
Кстати, знаете ли Вы, зачем перед файлом стоят два знака <. /> ?
Надеюсь, всем нам известна переменная PATH - в ней содержаться все каталоги, в которых могут быть исполняемые файлы. И когда пользователь пишет в терминале команду, linux ищет ее файл во всех каталогах, перечисленных в этой переменной.
Но ! Он не ищет этот файл в текущем каталоге, в котором стоит пользователь.
Именно для этого нужно писать эти два символа. Первый из них указывает, что файл находиться в текущей директории, второй-же служит разделителем между местоположением и именем файла.
Надеюсь, всем нам известна переменная PATH - в ней содержаться все каталоги, в которых могут быть исполняемые файлы. И когда пользователь пишет в терминале команду, linux ищет ее файл во всех каталогах, перечисленных в этой переменной.
Но ! Он не ищет этот файл в текущем каталоге, в котором стоит пользователь.
Именно для этого нужно писать эти два символа. Первый из них указывает, что файл находиться в текущей директории, второй-же служит разделителем между местоположением и именем файла.
При запуске скрипта конфигурации, Вы на самом деле ничего не компилируете. Настройка только проверяет Вашу систему и присваивает значения системо-зависимым переменным. Эти значения используются для генерации Makefile. Makefile, в свою очередь, используется для генерации исполняемого модуля. При запуске конфигурационного скрипта, Вы увидите кучу странных сообщений, прокручивающихся на экране. Это нормально, не волнуйтесь по этому поводу. Если конфигурация находит ошибку, она сообщает об этом и останавливает процесс. Однако, если все работает как нужно, утилита конфигурации не выводит ошибок и заканчивает свою работу.
Если конфигурация произошла без ошибок, самое время переходить к следующему шагу.
Шаг 3. Компилирование.
Итак, сейчас мы будем создавать из исходных текстов саму програму. Это делается путем запуска команды:
1 |
|
Обратите внимание, что эта команда требует наличие Makefile для создания программы. Если его нет, то команда будет не в курсе необходимых действий. Вот почему так важно запускать конфигурирование пакета, либо настраивать Makefile каким-либо другим способом. При запуске make Вы вновь увидите кучу странных сообщений, наполняющих Ваш экран. Это также совершенно нормально, и пускай это снова Вас не тревожит. Эта процедура может отнять некоторое время, в зависимости от того, насколько велика программа и насколько быстр Ваш компьютер. Если Вы делаете это на старых устаревших компьютерах, можете пойти попить кофе. На этом этапе я обычно совершенно теряю терпение.
Если все пройдет гладко, Ваш исполняемый модуль готов к запуску. Теперь перейдем к заключительному шагу, в котором будем устанавливать программу.
Шаг 4. Установка.
Наконец, пришло время установить программу. При этом Вы должны иметь права суперпользователя. Для этого перед командой добавим оператор sudo. Он запросит у Вас пароль администратора, и после этого запустит заключительный шаг:
1 |
|
Опять же, Вы получите странные сообщения на экран. После того, как они остановятся, и на экране не будет следов ошибок (например слова error), поздравляю: Вы уже установили программу, и готовы запустить ее.
Так как Мы в этом примере не изменяли поведение конфигурационного скрипта, программа была установлена в место по-умолчанию. Во многих случаях это /usr/local/bin. Если Вы уже находитесь в /usr/local/bin (или другом местe, в которое Вы установили программу), можете просто запустить программу, набрав ее название.
Удаление ненужных файлов.
Бьюсь об заклад, Вы хотите сэкономить место на диске. Если это так, Вы хотите, избавиться от некоторых файлов, которые Вам больше не понадобятся. Когда Вы запускали make — он создал все виды файлов, которые были необходимы в процессе компиляции, но оказались бесполезными сейчас, и только занимают место на диске. Вот как можно убрать ненужные файлы:
1 |
|
Однако убедитесь, что сохранили ваши Makefile. Они понадобятся, если позднее Вы решите удалить программу и захотите это сделать с минимальной головной болью.
Удаление программы.
Итак, Вы решили что Вам не нравится программа. Удаление собранных Вами программ так-же легко, как удаление программ, установленных менеджером пакетов, как, к примеру, rpm. Если Вы хотите удалить программное обеспечение, Вами-же собранное, необходимо снова почитать документацию, которая шла с пакетом. Там можно увидеть, упоминается ли там процедура удаления. Если там этого не описано, можете хвататься и рвать свои волосы.
Если Вы не удалили Makefile, Вы сможете удалить программу, выполнив команду:
1 |
|
Если Вы увидите странные прокрутки текста (Вы, вероятно, уже к этому привыкли ? :-) - это хороший признак. Если-же команда make начинает жаловаться и выдавать ошибки, то это признак плохой. Тогда следует удалить файлы программ вручную.
Если Вы знаете, где была установлена программа, Вам придется вручную удалить установочные файлы или каталоги, где находиться Ваша программа. Если Вы не знаете, где все эти файлы, Вам придется читать Makefile и смотреть, где эти файлы были установлены, и затем удалять их.
//offtopic mode on
Винда тоже ищет программы в установленных путях, типа PATH. Но, как обычно, этот момент они содрали криво, поэтому работает оно не всегда прозрачно и для нормальной работы пути эти надо полностью переписывать руками.
//offtopic mode off
Винда тоже ищет программы в установленных путях, типа PATH. Но, как обычно, этот момент они содрали криво, поэтому работает оно не всегда прозрачно и для нормальной работы пути эти надо полностью переписывать руками.
//offtopic mode off
Да, знаю. Если в активно использующейся винде с большим количеством установленных программ посмотреть на этот $PATH, то жутко станет, скольков сего туда понапихано... Помню, при установке чего-то хитропопого нужно было добавить туда что-то вручную, ох я был шокирован, когда его увидел...
А я когда mingw на винду ставил, так и не смог добиться, чтобы g++ в консоли работал, хотя добавлял :(
%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem;c:\matlab6p5\bin\win32;c:\mathcad11;c:\workbench
и это ещё не говоря про всякие mingw и тому подобные, а вот всё, что в линуксе:
~/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
так что, ИМХО в линуксе покороче будет
Лол. Шесть в винде и восемь в линуксе. Ну конечно в винде их больше, названия-то длиннее, да.
переменная короче - это меньше в ней содержимого.
%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem;%SYSTEMROOT%\System32\WindowsPowerShell\v1.0\;
По-моему, вот так выглядит дефолтная в семерке, в линуксе - все то, что ты написал, за исключением /usr/games.
О чем спор-то? Лишь бы померятся длинной чего-нить блин.
%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem;%SYSTEMROOT%\System32\WindowsPowerShell\v1.0\;
По-моему, вот так выглядит дефолтная в семерке, в линуксе - все то, что ты написал, за исключением /usr/games.
О чем спор-то? Лишь бы померятся длинной чего-нить блин.
Ха ! логично !
Спасибо за пояснения, сейчас постараюсь внести это в текст =)
И за ошибку спасибо, сейчас поправлю =)
Спасибо за пояснения, сейчас постараюсь внести это в текст =)
И за ошибку спасибо, сейчас поправлю =)
Инструкция, конечно, информативная, только вредная. Не надо так делать. Никогда! Если уж совсем приспичило - то надо собрать программу в пакет для своего дистра. Если неохота, то как минимум использовать checkinstall. Вот про него бы сюда добавить и будет отлично.
Ну и...
Ну и...
На дворе 2010-й год, на форуме опять ставят XMMS из исходников :)
(с) http://bash.org.ru/
да, действительно, checkinstall круче, сейчас прикручу оговорку, спасибо =)
1) насколька я знаю, при configure можно указать так называемый prefix- директорию, куда будет все ставиться.
2) выполни в консоли "echo $PATH" . Это пути, по которым ищутся исполняемые файлы. Когда пишешь в консоли просто python, или make, например, он пытается по этим путям именно найти их. Текущая папка почти наверняка не будет в PATH, поэтому просто командой myscript.sh ничего не запустится. А точка в bash обозначает текущую папку, чтобы не набирать постоянно её полный путь. Можно сделать "cd .", и перейдешь опять же в текущую папку) Ну а слеш отделяет файл от папки, поэтому и получается ./myscript.sh
3) install - опция программы make, так же как clean, uninstall и т.д) Ну а так по идее - да, просто говорит что надо скопировать в системные папки то, что накомпилил)
2) выполни в консоли "echo $PATH" . Это пути, по которым ищутся исполняемые файлы. Когда пишешь в консоли просто python, или make, например, он пытается по этим путям именно найти их. Текущая папка почти наверняка не будет в PATH, поэтому просто командой myscript.sh ничего не запустится. А точка в bash обозначает текущую папку, чтобы не набирать постоянно её полный путь. Можно сделать "cd .", и перейдешь опять же в текущую папку) Ну а слеш отделяет файл от папки, поэтому и получается ./myscript.sh
3) install - опция программы make, так же как clean, uninstall и т.д) Ну а так по идее - да, просто говорит что надо скопировать в системные папки то, что накомпилил)
3) install - опция программы make, так же как clean, uninstall и т.д) Ну а так по идее - да, просто говорит что надо скопировать в системные папки то, что накомпилил)
Спасибо. Просто в понимании windows - инсталляция это весь процесс конфигурирования/распаковки/копирования файлов.
Мне, к примеру, по началу совсем непонятно было, почему нельзя просто сделать make install, не отвлекаясь на промежуточные шаги =)
make install
Плохой совет, лучше использовать checkinstall, чтоб можно было снести пакетным менеджером.
Кстати, под рутом лучше не компилить. Пример - сделали make под рутом, установили - все хорошо, а потом обычным пользователем не удалим ненужные исходники(вдруг make uninstall на сработает). Поэтому лучше сделать просто ./configure , make и потом sudo make install :)
Вообще-то собирать лучше под fakeroot'ом (как это делает йогурт в арче)
Или в hasher'е в альтах
Или в hasher'е в альтах
Все было хорошо до ключевой фразы поста
Как узнать, что make жалуется или выдает ошибки? Ведь
1) ./configure --prefix=/путь/установки
2) так как пути к сценарию /path/to/your/program/configure нет в PATH
3) make install делает то, что указано в секции install файла Makefile
Если-же команда make начинает жаловаться и выдавать ошибки
Как узнать, что make жалуется или выдает ошибки? Ведь
получите странные сообщения на экран. После того, как они остановятся поздравляю
Если будут ошибки, сообщения все-равно остановятся, с чем же поздравляем?1) ./configure --prefix=/путь/установки
2) так как пути к сценарию /path/to/your/program/configure нет в PATH
3) make install делает то, что указано в секции install файла Makefile
Совершенно ламерский вопрос: а по умолчанию prefix какой? /usr/share или что?
у "хороших" програм /usr/local, у "плохих" /usr или вообще какой угодно
Если будут ошибки, сообщения все-равно остановятся, с чем же поздравляем?
Так было в оригинале... или я так перевел....
Сейчас несколько изменил текст...
Совершенно ламерский вопрос: а по умолчанию prefix какой? /usr/share или что?
Я думаю, в каждом случае по разному может прописываться пусть в файле configure.
Это ведь не системный файл, а скрипт, который идет в составе исходников...
Можно открыть какой-нибудь файловый менеджер, зайти в папку (архив) программы, найти там файл configure, открыть его на просмотр и сделать в тексте поиск по слову prefix - будет что-то типа ac_default_prefix=/usr/local/bin
Это ведь не системный файл, а скрипт, который идет в составе исходников...
Можно открыть какой-нибудь файловый менеджер, зайти в папку (архив) программы, найти там файл configure, открыть его на просмотр и сделать в тексте поиск по слову prefix - будет что-то типа ac_default_prefix=/usr/local/bin
добавил бы, например, про канпеляцию кансоли Qt-приложений - там через qmake и без ./configure зачастую.
ну, статья и так уже достаточно большая получилась...
Я думаю остальные виды сборок, через qmake и cmake нужно оформлять в виде другой статьи....
Да и я, честно говоря, не знаю еще когда какой вид сборки нужно использовать =(
Я думаю остальные виды сборок, через qmake и cmake нужно оформлять в виде другой статьи....
Да и я, честно говоря, не знаю еще когда какой вид сборки нужно использовать =(
=) поправил, спасибо )
А получилось случайно, еще не ко всему привык, по памяти пишу... отчего-то считал что именно так оно и пишется =)
А получилось случайно, еще не ко всему привык, по памяти пишу... отчего-то считал что именно так оно и пишется =)
Ваш пакет с расширением tar.bz2, то то необходимо
необходимо в параметрах указать, что это не сжатый tar-архив
Как это bz2 не сжатый?
Вам придется читать Makefile и смотреть, где эти файлы были установлены, и затем удалять их.
Я например так отлавливал установленные файлы:
./configure=/tmp/foodir
make && make install
дальше смотрел какие файлы и куда установились и удалял те же файлы только с другим prefix'ом
Спасибо за ошибку, поправил.
Эммм... соре, запарилсо, поправил =)
Как это bz2 не сжатый?
Эммм... соре, запарилсо, поправил =)
Не плохая статья.
Но мне, почему-то, не нравится фраза:
Не люблю, когда gzip и bzip2 называют архиватором... Tar это архиватор, а gzip - это компрессор.
Но мне, почему-то, не нравится фраза:
После укладки их всех вместе в архив, он был сжат архиватором gzip, и получил, как следствие, расширение gz.
Не люблю, когда gzip и bzip2 называют архиватором... Tar это архиватор, а gzip - это компрессор.
Ну, я надеюсь мне как начинающему в Линухе простительно.
В тексте выражение поправил.
Ушел читать про разницу в типах архивов....
В тексте выражение поправил.
Ушел читать про разницу в типах архивов....
Простительно. Но знать полезно.
А разница в том, что tar собирает несколько файлов в один архив, но при этом ничего не сжимает. А gzip только сжимает, но сжимает файлы по одному...
К стати, bzip2 тоже компрессор.
Опции тоже полезно было бы расписать.
-x = извлечь
-v = подробный режим. Показывает какие файлы распаковываются.
-z = указать, что используется gzip.
-j = указать, что используется bzip2.
-f = указать, с каким файлом работать. Требует после себя аргумента.
А разница в том, что tar собирает несколько файлов в один архив, но при этом ничего не сжимает. А gzip только сжимает, но сжимает файлы по одному...
Некоторые люди используют вместо компрессора gzip архиватор bzip2
К стати, bzip2 тоже компрессор.
Как Вы видите, для распаковки архива можно использовать команду tar с соответствующими опциями (xvzf)
Опции тоже полезно было бы расписать.
-x = извлечь
-v = подробный режим. Показывает какие файлы распаковываются.
-z = указать, что используется gzip.
-j = указать, что используется bzip2.
-f = указать, с каким файлом работать. Требует после себя аргумента.
А еще иногда можно сделать ./configure && make и найти бинарник в этой папке, например ./q4wine - будет работать и не нужно устанавливать. Правда не всегда.
Да, и еще не озвучен процесс компиляции в cmake
Да, и еще не озвучен процесс компиляции в cmake
Я обычно для порядку распаковываю все исходники в /usr/local/src:
me@puter: ~/dls/pkg$cd /usr/local/src
me@puter: /usr/local/src$ sudo tar -xvf ~/dls/pk
=)
Места у меня хватает, так что на всякий пожарный не удалаяю исходники, так и живут там, никому не мешая.
Дико плюсую коммент cppmm
... хоть и не делаю такое никогда=)
me@puter: ~/dls/pkg$cd /usr/local/src
me@puter: /usr/local/src$ sudo tar -xvf ~/dls/pk
=)
Места у меня хватает, так что на всякий пожарный не удалаяю исходники, так и живут там, никому не мешая.
Дико плюсую коммент cppmm
Если уж совсем приспичило - то надо собрать программу в пакет для своего дистра.
... хоть и не делаю такое никогда=)
Хорошо разжёвано, для новичка самое оно.
Алсо,
> Вам не нравиться программа
http://tsya.ru
Алсо,
> Вам не нравиться программа
http://tsya.ru
Алсо,
> Вам не нравиться программа
http://tsya.ru
> Вам не нравиться программа
http://tsya.ru
Также: Что делает - нравится.
Спасибо, поправил =)
Для новичков, которым без GUI тяжело и использующих deb based дистрибутивы советую http://giftwrap.tuxfamily.org/
А в статье указано, что в архиве могут быть бинарники, а не сорцы?
эээммм... ну в статье как-бы рассказывается как собрать из исходников....
>В принципе, большинство ПО можно взять в репозитариях той или иной операционной системы, но иногда мы встречаем на сайте программу в виде tar.gz или tar.bz2 файлов.
Не факт, что это сорцы
Не факт, что это сорцы
Я обычно делаю ./configure --help, вдруг надо добавить или убрать что-то.
Хотя, если readme толковый, там должны быть описания опций.
Хотя, если readme толковый, там должны быть описания опций.
А на вопрос про <./> даже я, хоть и ламер во многом, ответ знаю. Linux, в отличие от Windows, ищет запускаемые файлы только в установленных путях $PATH (это всякие /bin, /usr/bin, ~/bin и может ещё что-то где-то), но НЕ ищет их в текущей директории. То есть если ввести "configure", то Linux поищет файл configure во всех этих папках, не найдёт, плюнет и ничего делать не станет. Выхода два - либо указывать абсолютный путь (/home/me/dls/package/configure или как там в примере выходит), или относительный, но так чтобы было понятно, что это именно путь, а не призыв искать команду в папках их $PATH. Точка обозначает текущую директорию (так же как две точки обозначают директорию уровнем выше), и таким образом путь ./configure указывает на файл configure в текущей папке. Знающие люди поправят, если я чего напутал.
За статью спасибо, хоть что-то понятно стало наконец. Может, в следующий раз даже не побоюсь установить что-то из исходников через консоль...