установка файлов в REDHAT клонах включая ALT LINUX и их конфигурация
ля тех, кто не знает: тарболл -- это заtarенный и, как правило, заgzipенный набор исходных файлов, из которых можно скомпилировать в программу; обычно файловое имя тарболла либо "progfile-1.23.tgz", либо "progfile-1.23.tar.gz", где "progfile" - это название программы, а "1.23" (разумеется, числа могут быть любыми) соответствует номеру версии. Когда вы устанавливаете пакет -- неважно, RPM, DEB или что-то другое, используемое в вашем дистрибутиве, -- вы просто помещаете библиотеки, документацию и уже откомпилированный бинарный файл(ы) в соответствующие каталоги. Компиляция исходных файлов -- это работа, которую обычно выполняют для вас люди, сопровождающие пакет (мэйнтейнеры).
После того, как я скачал тарболл в свой подкаталог "/home/ben/TGZs", специально созданый мною для хранения скачанных тарболлов, я скопировал его в "/tmp" -- мне нравится компилировать исходные файлы там. Кстати, некоторые предпочитают это делать в "~/tmp" - подкаталоге своего домашнего каталога: причина в том, что "/tmp" обычно очищается во время загрузки, а компиляция, преведшая К ДЕЙСТВИТЕЛЬНО СЕРЬЕЗНОЙ ошибке может "подвесить" машину... что потребует перезагрузки (о-опс!). Не берусь опровергать эту точку зрения, но сам продолжаю оставаться чертовски рисковым парнем -- я доверяю своему Linux. smile
Файл назывался "cuyo-1.03.tar.gz" - поэтому соответствующей магией, превращающей его обратно в полезные файлы, будет
tar xvzf cuyo-1.03.tar.gz
Эта команда создаст каталог с именем "cuyo-1.03" прямо в "/tmp".
(Вообще-то, я сделал не совсем так -- я заш?л внутрь тарболла с помощью Midnight Commander'а, открыл во второй панели "/tmp" и нажал "F5", чтобы скопировать сжатый каталог. Я привел здесь это заклинание для тех, кто хочет или вынужден проделывать вс? это вручную.)
Учтите, что некоторые авторы программ не столь любезны при сборке своих тарболлов: иногда такое расtarивание приводит к копированию всех файлов в текущий каталог. Страшная путаница, особенно, если это ваш домашний каталог! Несколько дюжин файлов перемешиваются с вашими, в придачу к ним кучка каталогов -- а уж если если имена некоторых файлов совпадут с именами ваших файлов... (не то, что ваши файлы будут заменены, но все равно путаница ещ? та) или каталогов (пакет будет скопирован в них, и вам потом нужно будет вс? это вычищать). Как примитивно! Вот почему я люблю заходить в тарболлы и копировать вместо обычного разtarивания. Те, кто не использует Midnight Commander или другой файловый менеджер, могут заглянуть внутрь тарболла просто выполнив команду
tar tvf
Вы увидете содержимое архива, и берегитесь, если перед именем каждого файла не стоит имя каталога! Ну, конечно, не так вс? страшно: вс?, что вам нужно сделать -- создать каталог (если вы дадите ему имя тарболла "progname", то потом вы не забудете, что там находится) и расtarить файл внутрь него.
mkdir rudeprogram-6.66
tar xvf rudeprogram-6.66.tgz -C rudeprogram-6.66
Теперь все файлы из тарболла "rudeprogram" будут извлечены в указанный подкаталог.
К счастью, автор "cuyo" был культурным товарищем (как и большинство авторов программ), и "cuyo" был заtarен прямо в собственном подкаталоге. Внутри был набор файлов, включая те, которые вы должны изучить перед началом работы: "README" и "INSTALL". В первом обычно содержатся авторские инструкции, рекомендации и т.п. Второй -- достаточно стандартный, в н?м объясняется работа скрипта "configure", весьма крутой программы, обычно создаваемой утилитой "autoconf", которая изучает вашу систему и корректно (ну, почти корректно) создает Makefile, необходимый для сборки программы. Огромное преимущество этого метода в том, что если автор был внимателен при написании своей программы, "configure" создаст правильный Makefile для любой версии Unix и, возможно, даже для других OS.
Позвольте мне на минутку отвлечься: некоторые программы настолько просты, что не требуют "configure", а поставляются просто с Makefile (его имя может начинаться с большой буквы или полностью пишется строчными). Другие -- ещ? проще, вс?, что вы увидите -- это один единственный "progfile.c" или "progfile.cc". Для них, в первом случае нужно просто выполнить "make", а во втором -- "cc progfile.c -o progfile".
Как бы то ни было, я запустил "configure" в подкаталоге "cuyo" -- он немного "пожевал" мою систему, что является его работой, и создал Makefile. Что могло быть лучше? smile Хотя была небольшая проблема - "configure" во время работы выводит сообщения и предупреждает вас в случае отказов (обычно останавливаясь и печатая ошибку.) Сообщение, которое он мне выдал, правда, без остановки, было такое:
checking the Qt meta object compiler... (cached) failure
>configure: warning: Your Qt installation seems to be broken!
Хм-м. Ну он же вс?-таки сделал makefile. Обычно нефатальные ошибки просто означают, что вы не получите каких-либо возможностей программы, но е? вс?-ещ? можно скомпилировать. Давайте попробуем.
Я запустил "make" -- просто в командной строке набрал "make" -- который по умолчанию читает "Makefile" (или "makefile") и выполняет команды, соответствующие цели "all" и тут...
О-опс. Он обвалился.
Это и был момент, когда я решил написать эту статью. До этого я не думал делать это -- вообще-то, в этом месяце у меня было много работы -- но мне кажется, что установка из тарболлов -- навык, необходимый каждому пользователю Linux, и моей мыслью было задокументировать весь процесс, включая поиск ошибок в неправильно выполняющейся установке. Это то, с чем я боролся в свои первые дни в Linux, и я хотел бы уберечь других от этих мучений. smile
Итак. Мы смело продолжаем. Когда я сказал, что он обвалился, что конкретно я видел? Ну, "make" должен выполняться без ошибок. Иногда -- часто -- вы будете получать предупреждения, но это другое -- просто библиотеки у вас могут слегка отличаться, или, возможно, ваш компилятор несколько более строг к объявлениям -- обычно это не фатально. Ошибки, из-за которых вы вываливаетесь из компиляции до ее завершения -- вот их то мы и должны исправить. Вот как это выглядело:
Baldur:/tmp/cuyo-1.03$ make
make all-recursive
make[1]: Entering directory `/tmp/cuyo-1.03'
Making all in src
make[2]: Entering directory `/tmp/cuyo-1.03/src'
c++ -DHAVE_CONFIG_H -I. -I. -I.. -DPKGDATADIR=\"/usr/local/share/cuyo\"
-Wall -ansi -pedantic -c bildchenptr.cpp
In file included from bildchenptr.h:21,
from bildchenptr.cpp:18:
inkompatibel.h:13: qglobal.h: No such file or directory
make[2]: ** [bildchenptr.o] Error 1
make[2]: Leaving directory `/tmp/cuyo-1.03/src'
make[1]: [all-recursive] Error 1
make[1]: Leaving directory `/tmp/cuyo-1.03'
make: * [all-recursive-am] Error 2
Baldur:/tmp/cuyo-1.03$
Начало ошибки начинается со строки "In file included..." и заканчивается (по крайней мере, та часть, которая нам нужна) словами "...qglobal.h: No such file or directory". Понятно, не хватает заголовочного файла. Я быстренько просмотрел дерево исходных файлов "cuyo", чтобы проверить, что автор не забыл включить один из собственных файлов (да, бывает) -- ничего. Видимо, это один из моих -- так и есть, программа должна найти файл, поставляемый с библиотекой, которую я должен был иметь в своей системе для компиляции программы. Хмм. А какая? Разумеется, та, которая содержит "qgloval.h".
В моей системе есть несколько скриптов, которые помогают мне в работе со стандартыми задачами установки. Один из них - "pkgf" - он ищет нужный мне файл во вс?м дистрибутиве Debian и сообщает, в каком пакете этот файл находится. (Это не то же, что "dpkg -S ", который делает это только для установленных пакетов). Если вы используете Debian, то сможете получить такую же функцию, скачав текущий "Packages.gz" с и zgrepпнув в н?м (поискать с помощью утилиты zgrep) имя файла, или просто сходите на и воспользуйтесь их утилитой поиска. Смысл в том, чтобы найти пакет с "qglobal.h" и установить его.
pkgf "qglobal.h"
usr/include/qt/qglobal.h devel/libqt-dev
devel/libqt3-emb-dev
devel/libqt3-dev
devel/libqt-emb-dev
Так, так - похоже, мне нужно выбирать из нескольких пакетов. Хорошо, "libqt3-dev", вроде, самый последний:
apt-get install libqt3-dev
Установка прошла достаточно быстро, и... я снова получил ту же ошибку, когда ещ? раз запустил "make". То же будет и у вас. Поэтому, не делайте так. Не следует забывать (а я знал, что будет ошибка -- я это сделал, чтобы привлечь ваше внимание), что вы уже выполнили "./configure" и старые (неверные) значения вс? ещ? содержатся в Makefile, а также в нескольких других файлах, поэтому, вместо того, чтобы впустую тратить время на выяснение, где они могут быть, сделайте так:
ben@Baldur:/tmp/cuyo-1.03$ cd ..
ben@Baldur:/tmp$ rm -rf cuyo-1.03
ben@Baldur:/tmp$ tar xvzf ~/TGZs/cuyo-1.03.tar.gz -C .
ben@Baldur:/tmp$ cd cuyo-1.03
Другими словами, я просто целиком "сн?с" каталог "cuyo" и заменил его свежей копией исходных файлов. Это хорошее правило: при сомнениях вернуться к первоначальным исходным файлам. Верите или нет, я научился этому трюку от корабельного механика, который необычно хорошо справлялся со своей работой. Кенни изложил его такими словами: "верни все к заведомо рабочему состоянию и начинай оттуда". Я не видел, чтобы его совет не сработал; известно, что клиенты склоны вопить, когда ты говоришь, что должен удалить часть засоренного софта, стоящего в данный момент, и устанавливать с нуля... но, немного погодя, слышишь: "Э-э, а этот парень неплохо все сделал". Так можно потерять часть сделанной работы -- у меня так бывало -- но, как Кенни, я не хочу, чтобы мо? имя стояло на барахле.
Знаю, знаю -- я говорю на общие темы, а не о старой доброй установке тарболла. Суть в том, что надо понимать "философию" того, чем вы собираетесь заниматься, и лучше понять методологию и особенности работы до того, как вы начнете реально что-либо делать. Хорошо, верн?мся к главному вопросу -- программа заработала или нет???
ben@Baldur:/tmp/cuyo-1.03$ ./configure
ben@Baldur:/tmp/cuyo-1.03$ make
make[2]: Leaving directory `/tmp/cuyo-1.03/src'
Making all in data
make[2]: Entering directory `/tmp/cuyo-1.03/data'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/tmp/cuyo-1.03/data'
Making all in docs
make[2]: Entering directory `/tmp/cuyo-1.03/docs'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/tmp/cuyo-1.03/docs'
make[2]: Entering directory `/tmp/cuyo-1.03'
make[2]: Nothing to be done for `all-am'.
make[2]: Leaving directory `/tmp/cuyo-1.03'
make[1]: Leaving directory `/tmp/cuyo-1.03'
ben@Baldur:/tmp/cuyo-1.03$
Ураааа!!! Ошибок нет -- и когда я вош?л в каталог "cuyo-1.03/src", там был очень миленький бинарничек под названием "cuyo". Теперь, если я хочу продолжить установку (а не просто посмотреть, понравится ли мне игра), мне надо ввести
make install
Будет прочитан Makefile и выполнятся все команды для цели "install", которые, скорее всего, установят бинарник(и), страницы man и документацию. Однако у меня есть склонность сначала поиграться с программой и посмотреть, нравится ли она мне, поскольку в большинстве тарболлов make-файлы не содержат цель "uninstall" (по-моему, это стыдно, ведь это сделало бы тарболл-пакеты почти такими же л?гкими в установке и удалении, как, скажем, RPM или DEB).
Перечислим всю процедуру установки тарболла:
Проверить, содержит ли он каталог или файлы просто (как некультурно!) свалены в него.
Разtarте в каталог "/tmp" или "~/tmp"
Выполните "configure", если он есть.
Выполните "make" или, в случае единственного простого "file.c" или "file.cc", команду "cc".
Выполните "make install", если результат получился тот, что вы ожидали.
Это почти вс?. Обратите внимание, что я не обсуждал здесь вопросы безопасности (действительно ли вы доверяете автору этого тарболла или пакета? Никогда не заходите рутом, чтобы поиграться с бинарником, ладно?), ни многие другие аспекты, касающиеся системного администрирования -- эти аспекты очень важны и необходимы, однако, не рассматриваются этой короткой статье. Мудрый системный администратор -- а это, мой дорогой домашний пользователь Linux, вы, больше за вашей машиной никого нет! -- должен много читать, размышлять, пытаясь проникнуть в суть происходящего, и принимать мудрые решения.
статья взята из фонда свободного программного обеспечения FSF - Free Software Foundation.. с которым я очень дружу)))))
