|
|
|
|
|
|
|
Автор: Ben Okopnik Как-то раз я решил скачать "cuyo" (смотрите в этом выпуске обзор http://www.linuxgazette.com/lissue74/orr3.html Mik'а Orr'а) -- новую игру, о которой упоминалось в рассылке Answer Gang admin. Однако, зайдя на веб-сайт, вместо пакета для установки я нашел только тарболл с исходными файлами, хотя в письме упоминалось, что должен иметься архивный пакет для Debian. "Ничего сложного," -- подумал я -- "я делал это и раньше..." [Пакет cuyo .deb есть в нестабильной ветви дистрибутива Debian. Но эта статья применима к любой программе, которая либо не входит в ваш дистрибутив, либо версия дистрибутиве устарела или неадекватна, но которую вы, тем не менее, хотите установить. -Iron.] Для тех, кто не знает: тарболл -- это заtarенный и, как правило, заgzipенный набор исходных файлов, из которых можно скомпилировать в программу; обычно файловое имя тарболла либо "progfile-1.23.tgz", либо "progfile-1.23.tar.gz", где "progfile" - это название программы, а "1.23" (разумеется, числа могут быть любыми) соответствует номеру версии. Когда вы устанавливаете пакет -- неважно, RPM, DEB или что-то другое, используемое в вашем дистрибутиве, -- вы просто помещаете библиотеки, документацию и уже откомпилированный бинарный файл(ы) в соответствующие каталоги. Компиляция исходных файлов -- это работа, которую обычно выполняют для вас люди, сопровождающие пакет (мэйнтейнеры). После того, как я скачал тарболл в свой подкаталог "/home/ben/TGZs", специально созданый мною для хранения скачанных тарболлов, я скопировал его в "/tmp" -- мне нравится компилировать исходные файлы там. Кстати, некоторые предпочитают это делать в "~/tmp" - подкаталоге своего домашнего каталога: причина в том, что "/tmp" обычно очищается во время загрузки, а компиляция, преведшая К ДЕЙСТВИТЕЛЬНО СЕРЬЕЗНОЙ ошибке может "подвесить" машину... что потребует перезагрузки (о-опс!). Не берусь опровергать эту точку зрения, но сам продолжаю оставаться рисковым парнем -- я доверяю своему Linux. :) Файл назывался "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 <filename> Вы увидете содержимое архива, и берегитесь, если перед именем каждого файла не стоит имя каталога! Ну, конечно, не так все страшно: все, что вам нужно сделать -- создать каталог (если вы дадите ему имя тарболла "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. Что могло быть лучше? :) Хотя была небольшая проблема - "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, и я хотел бы уберечь других от этих мучений. :) Итак. Мы смело продолжаем. Когда я сказал, что он обвалился, что конкретно я виделе Ну, "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 <file>", который делает это только для установленных пакетов). Если вы используете Debian, то сможете получить такую же функцию, скачав текущий "Packages.gz" с <ftp://ftp.debian.org> и zgrepпнув в нем (поискать с помощью утилиты zgrep) имя файла, или просто сходите на <http://www.debian.org/Packages> и воспользуйтесь их утилитой поиска. Смысл в том, чтобы найти пакет с "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
<No errors>
ben@Baldur:/tmp/cuyo-1.03$ make
<lots of output elided>
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). Перечислим всю процедуру установки тарболла:
Это почти все. Обратите внимание, что я не обсуждал здесь вопросы безопасности (действительно ли вы доверяете автору этого тарболла или пакета? Никогда не заходите рутом, чтобы поиграться с бинарником, ладно?), ни многие другие аспекты, касающиеся системного администрирования -- эти аспекты очень важны и необходимы, однако, не рассматриваются этой короткой статье. Мудрый системный администратор -- а это, мой дорогой домашний пользователь Linux, вы, больше за вашей машиной никого нет! -- должен много читать, размышлять, пытаясь проникнуть в суть происходящего, и принимать мудрые решения. Удачи, и да будут все ваши зависимости разрешены. :) |
Новости сайта
Антивирус
