Скорее всего в tar.gz/tar.bz2 лежит не программа, а ее исходники (иногда исходники с собранной программой).
Прежде чем ее ставить, нам необходимо ее собрать. Для этого нужно выполнить (не бросайтесь сразу это делать):
root@linux# ./configure
root@linux# make
root@linux# make install
Если после любого из пунктов возникли сообщения об ошибках, значит не все вышло так, как хотелось. Можно попробовать `./configure --help` для вывода опций настройки и попробовать использовать некоторые из них.
Поскольку при таком способе установки информация о том, что ставилось и куда, остается только в памяти админа (которая частенько еще какая временная :), лучше для контроля этого процесса использовать checkinstall - http://checkinstall.izto.org, или похожие программы (почему выше и мы говорили не выполнять команды сразу).
После того, как вы ее установите (прочитав документацию) и настроите ее конфиг, на этапе установки программного обеспечения вместо sudo make install будете писать sudo checkinstall. Checkinstall соберет "настоящий" пакет для указанной (tgz, rpm и deb в зависимости от настроек), установит его в систему и поместит в указанный в конфигурационном файле каталог (удобно для централизованного обновления нескольких машин). Удаление установленных таким образом программ осуществляется стандартными средствами дистрибутива, например, removepkg для Slackware.
Также будет полезным прочитать о том, как уменьшить размер бинарных файлов.
Если вы пренебрегли нашим советом и собрали и поставили программу не используя специальных утилит (или своего менеджера пакетов), тогда нужно заново распаковать исходники (ведь вы после сборки наверняка удалили папку, в которой собирали программу), сконфигурировать ее с теми же параметрами (напрягайте память), но вместо make install сделать make uninstall. Если повезет, то все удалится.
A: Это неоднозначный вопрос. Дело в том, что если вы просто собрали программу с помощью
root@linux# ./configure
root@linux# make
root@linux# make install
то все зависит лишь от того, позаботился ли автор об удалении.
Для того, чтобы удалить программу, нужно зайти в каталог ее исходников, из которого она собиралась, и сделать make uninstall.
Если каталог не сохранился, распакуйте исходники, сделайте ./configure с теми же параметрами, с которыми собирали программу, и выполните make uninstall.
А чтобы не полагаться на приличия автора, рекомендуется посмотреть предыдущий вопрос,
Внимание: в rpm-based дистрибутивах собирайте программы из srpm или с использованием spec-файлов (для создания rpm). Не превращайте свою систему в помойку из программ.
По умолчанию программы собираются с отладочной информацией. Это, соответственно, увеличивает их размер, но на быстродействие и занимаемую оперативную память не влияет.
Можно собрать программу без отладочной информации, указав
./configure --disable-debug
Удалить секции с отладочной информацией из уже собранной программы можно командой
user@linux# strip progfile
Посмотреть, что вышло можно командой
user@linux# file progfile
она напишет - stripped или not stripped.
Можно сделать более правильно:
find . | xargs file | grep "executable" | grep ELF | cut -f 1 -d : | xargs strip --strip-unneeded
find . | xargs file | grep "shared object" | grep ELF | cut -f 1 -d : | xargs strip --strip-unneeded
Чтобы не делать изменения в рабочих макросах, создается файл /etc/rpm/macros, лучше в него все прописать:
%debug_package %{nil}
%_missing_doc_files_terminate_build 0
%_unpackaged_files_terminate_build 0
%__os_install_post \
/usr/lib/rpm/redhat/brp-compress \
/usr/lib/rpm/redhat/brp-strip %{__strip} \
/usr/lib/rpm/redhat/brp-strip-shared %{__strip} \
/usr/lib/rpm/redhat/brp-strip-static-archive %{__strip} \
/usr/lib/rpm/redhat/brp-strip-comment-note %{__strip} %{__objdump} \
%{nil}
В будущем при смене версии rpm, не придется ничего править в самих макросах из rpm.
Для сборки нужны заголовочные файлы(headers). Во многих дистрибутивах библиотеки(программы) поделены на два пакета - xxx и xxx-devel(rh-based) и xxx-dev(debian).
Соответственно нужно поставить xxx-devel (xxx-dev).
Примечание - в пакетах Slackware всё вместе (ну, кроме xfree86-devel).
Для redhat < 8.0, ASP Linux < 9 и Mandrake -
root@linux# rpm --rebuild название_пакета.src.rpm
Для redhat > 8.0, Fedora Core и ASP Linux = 9 -
root@linux# rpmbuild --rebuild название_пакета.src.rpm
Для Alt Linux:
root@linux# rpm-build -- rebuild название_пакета.src.rpm
Если вместо ожидаемого результата, на экран выводится список параметров командной строки, нужно установить rpm-devel. Ну а если все получилось, то пакеты будут лежать в /usr/src/название_дистрибутива/BUILD/название_архитектуры_процессора, например
/usr/src/redhat/BUILD/i386.
Читайте статью - фактически это пошаговое руководство.
http://gazette.lrn.ru/lg81/vikas.html
Помогаем:
Русское пошаговое описание для новичков
Если у вас rpm-based дистрибутив, тогда прочитайте сначала этот вопрос.
Поскольку у меня (jackill) Fedora Core, то рассматривать мы будем именно ядра Fedora Core. Для других дистрибутивов чуть-чуть будут отличаться пути в /usr/src и, возможно, названия spec-файлов.
Мы скачали пакет вида kernel-2.x.x-1.xxx.src.rpm. Нас устраивает конфигурация по умолчанию, но не устраивает сборка под i386. Поэтому пишем:
root@localhost# rpmbuild --rebuild --target=i686
и забираем из /usr/src/redhat/RPMS/i686 наши ядра (обычное и smp).
Распакуем srpm:
root@localhost# rpm -i kernel-2.x.x-1.xxx.src.rpm
Далее перейдем в каталог /usr/src/redhat/SPECS и распакуем сами исходники, наложив при этом все патчи:
root@localhost# rpmbuild -bp --target=i686 kernel-2.x.spec
Теперь переходим в папку /usr/src/redhat/BUILD/kernel-2.x/linux-2.6/
Это исходники ядра с соответствующим конфигом. Здесь выполним две команды:
root@localhost# make oldconfig
root@localhost# make menuconfig
Теперь мы можем выставить желаемые параметры. В качестве помощи можете воспользоваться этим разделом. Я обычно включаю поддержку NTFS, выбираю свой тип процессора, убираю поддержку 4ГБ памяти, ставлю соответствующие параметры для samba, а если машина в домене MS Windows 2003, то добавляю поддержку CIFS, а лишнее убиваю.
После того, как вы закончили выставлять параметры, мы переименовываем наш файл конфигурации .config, например в kernel-2.6.8-i686.config и переписываем в папку /usr/src/redhat/SOURCES.
Далее в kernel-2.x.spec выставляем какое нам нужно собрать ядро (обычное или smp), нужно ли собирать пакет с исходниками и пакет с документацией:
Summary: The Linux kernel (the core of the Linux operating system)
# What parts do we want to build? We must build at least one kernel.
# These are the kernels that are built IF the architecture allows it.
%define buildup 1
%define buildsmp 0
%define buildsource 1
%define builddoc 0
После строим как обычно.
Алгоритм простой:
Накладываем этот патч на распакованные исходники, конфигурируем ядро, переписываем так же получившийся конфиг, затем прописываем патч в kernel.spec (в двух местах: в одном сам патч, например Patch10002: vesafb-tng-0.9-rc4-r3-2.6.9-rc3.patch, во втором способ его наложения, например, Patch10002 -p1 - все увидите и сделаете по аналогии).
Если после этого на сборке ядро вылетает, придется сделать make oldconfig для всех файлов конфигурации (повод научиться писать скрипты ;), или убить все конфиги, кроме нужного вам, после чего повторить сборку.
Правда все просто?
Вообще было бы неплохо просто сделать man patch и все стало бы ясно (кстати, сделайте).
А как накладывать патчи на ядро написано в самом README к ядру. Тем не менее.
patch -p1 < my_patch.patch
p1 - уровень. Т.е. я захожу в каталог, где непосредственно находятся нужные мне файлы, копирую туда патч и оттуда запускаю эту команду.
p0 - нулевой уровень вложенности
Это патчи вида mypatch.gz и mypatch.bz2, соответственно:
bzip2 -dc mypatch.bz2 | patch -p0
gzip -cd mypatch.gz | patch -p0
Чтобы убрать патч, нужно добавить в команду patch ключик -R
Пример. Есть ядро версии 2.6.6. Надо получить ядро 2.6.9. Нужно ли накладывать ли patch-2.6.7 и patch-2.6.8? Нужно.
Это ссылка на домашнюю страницу проекта, однако она какая-то мертвая.
Зато очень живая страница товарища Con Kolivas. В своих патчсетах он использует supermount. И все, что он использует, можно по отдельности забрать отсюда.
Установите ncurses-devel (ncurses-dev) или как он там называется в вашем дистрибутиве.
Монолит хорош только тем, что у атакующего нет возможности подменить модуль своим. На этом плюсы кончаются. Ни скоростью работы, ни чем-либо другим ядро с модулями не отличается от ядра без модулей.
У модулей, однако, есть преимущество. Модулю можно передать параметры. Яркий пример - модуль bttv. Модули можно выгружать.
Можно попробовать включить в ядре параметр CONFIG_BSD_PROCESS_ACCT пересобрать его.
Можно использовать garnome.
Есть два варианта. Можно собрать KDE, используя утилиту konstruct.
Можно собрать из исходников. Порядок описан здесь.
Вкратце:
Придется наложить патч:
--- socks5/lib/confutil.c.orig 2004-11-05 20:05:57.582886240 +0300
+++ socks5/lib/confutil.c 2004-11-05 20:00:07.250144912 +0300
@@ -1156,7 +1156,7 @@
*cnt = j;
*intfc = pintfc;
- free(ibuf);
+ if(ibuf) free(ibuf); //check McMCC
#else
strcpy(pintfc[j].name, ibuf[i].ifr_name);
pintfc[j].up = lsLookupIntfc(s, NET_STAT, &ibuf[i]);
Спасибо McMCC
Вот инструкция по сборке:
http://tools.openoffice.org/dev_docs/build_linux.html
Довольно полная таблица по параметрам карточек, которые можно прописать в /etc/modules.conf (для 2.4.х) или в /etc/modprobe.conf (для 2.6.х).
http://www.startcom.org/docs/en/Reference Guide StartCom Enterprise Linux 3.0.x/s1-modules-ethernet.html
Для карт realtek 8139 можно указать параметр media=0x0030
К тому же есть инструменты ethertools и mii.