Как из исходного кода сделать приложение
Перейти к содержимому

Как из исходного кода сделать приложение

  • автор:

Как из исходного кода сделать приложение

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

Таким образом можно проконтролировать, что приложение правильно собирается, соответствует исходному коду и содержит только свободное ПО. К сожалению, часто бывает, что приложение, поставляемое в виде бинарного APK и заявленное как свободное ПО, оказывается с сюрпризом (или несколькими):

  1. Исходный код (конкретной версии или даже всех имеющихся версий) недоделанный или вообще отсутствует.
  2. Из исходного кода невозможно собрать предоставленный APK.
  3. В так называемом исходном коде есть бинарные файлы непонятного происхождения или файлы с проприетарной лицензией.

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

Обратите внимание: во время сборки приложения из исходного кода вы подписываете его вашим собственным ключом (на устройство Android можно установить только подписанное приложение). Если на устройстве установлена предыдущая версия приложения, подписанная другим ключом, ее придется удалить перед установкой текущей версии (т.е. невозможно обновить версию, если ключи отличаются). Такой подход добавляет пользователям хлопот, потому что при удалении приложения теряются все его данные.

Управлять репозиторием для приложения, собранного из исходного кода, нетрудно (схема действий очень похожа на описанную в главе “Простой репозиторий с бинарными файлами”), с небольшими дополнениями:

  1. Включайте сведения о сборке (из каких коммитов какие версии собирать) в файлы метаданных.
  2. Выполняйте команду fdroid build для любых еще не собранных приложений.
  3. Выполняйте команду fdroid publish для упаковки и подписи любых собранных APK.

Директория с данными приложения (fdroiddata)

Для любых задач вам понадобится как минимум одна директория с каталогом данных самого репозитория. Именно в ней выполняют команды fdroid для управления репозиторием. Можно создать ее с нуля, а можно скопировать уже имеющуюся из основного репозитория F-Droid:

git clone https://gitlab.com/fdroid/fdroiddata.git 

Для любых задач и корректной работы инструментов управления необходимо добавить основные настройки в конфигурационный файл config.yml (его нужно создать в директории с каталогом данных репозитория). Для этого скопируйте шаблонный файл ./examples/config.yml из проекта fdroidserver в эту директорию и поправьте согласно содержащимся в нем инструкциям.

После этого вам становятся доступны все инструменты, нужно лишь выполнить команду fdroid . Чтобы посмотреть, какие, можно запустить эту команду без опций.

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

fdroid update --help 

Подробнее об fdroid build

Если запустить команду fdroid build без дополнительных параметров, она соберет все версии приложения, которых еще нет в директории repo (точнее, в директории unsigned ). Вы можете сделать миллион других вещей ( —help вам в помощь при работе с инструментами fdroid ), а ниже — несколько типичых примеров использования команды с пояснениями:

Чтобы собрать отдельно взятую версию какого-либо приложения, можно выполнить команду:

fdroid build org.fdroid.fdroid:16 

Эта команда соберет код для 16 версии (versionCode) клиента F-Droid (versionName 0.25). Большинство инструментов распознает аргументы команды как имена пакетов, что позволяет им работать только с обозначенным набором пакетов.

Если сборка прошла без ошибок, то в директории unsigned появятся два файла:

org.fdroid.fdroid_16.apk org.fdroid.fdroid_16_src.tar.gz 

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

Если вы собираетесь опубликовать эти файлы, то необходимо выполнить вот эту команду:

fdroid publish 

Архив с исходным кодом будет помещен в директорию repo (каталог, который вы отправляете на веб-сервер). Туда же попадет оптимизированная и подписанная версия приложения (файл APK). Оба файла будут удалены из директории unsigned .

Если сборка происходит в тестовых целях, и результаты не предназначены для публикации в репозитории, то можно указать опцию —test , чтобы помещать результирующие файлы не в директорию unsigned , а в директорию tmp . Можно, конечно, просто-напросто удалить эти файлы из unsigned вручную после окончания сборки, но всегда есть риск, что вы забудете это сделать!

Аналогичным образом можно использовать опцию —force (только вместе с опцией —test !) для принудительной сборки отключенных приложений (обычно их не собирают). Так же принудительно можно собрать версии приложений со включенными в них ELF файлами и несвободными библиотеками (см. scanignore и scandelete в разделе Cборки ).

Если приложение не собралось, логи сборки можно посмотреть в директории logs/. Если после просмотра логов просветления не наступило (а такое бывает!), попробуйте собрать приложение старым добрым способом, шаг за шагом: android update project, ndk-build и ant debug.

Следует помнить, что в репозитории с исходным кодом очень часто включают заранее собранные библиотеки. Если вы планируете выложить приложение в основной репозиторий F-Droid, стоит убедиться, что все предварительные сборки выполнены или согласно инструкциям из файла метаданных, или внушающей доверие третьей стороной.

Запуск fdroid build в исходном коде приложения

fdroid build может использовать файл метаданных из исходного кода приложения (а не из папки metadata/, где сложена гора других приложений). Этот файл метаданных (.fdroid.yml) обязательно должен лежать в корне вашего репозитория с исходниками.

При такой схеме действий можно собрать самую свежую версию приложения, используя весь набор инструментов F-Droid. Выполняйте команду:

fdroid build 

Если хочется собрать все существующие версии, добавьте —all .

Прямая установка на устройство

Можно объединить сборку и установку на подключенное устройство (или эмулятор) командой fdroid install . Если сделать это без указания конкретных пакетов (их передают в виде аргументов), то в результате вы получите самые свежие (собранные и подписанные) версии всех имеющихся приложений. Скорей всего, это не то, что сердце просит, поэтому установка прервется. Тем не менее, если хочется именно этого, то защиту от невнимательных можно перешагнуть, указав опцию —all . Сейчас проверок работоспособности приложений для этого режима нет, поэтому даже если файлы из подписанной результирующей директории поменялись, вам об этом никто не скажет.

Модификация исходного кода android-приложения с использованием apk-файла

Так уж получилось, что приложение для чтения комиксов и манги, которое я использую на своем android-смартфоне, после обновления стало показывать рекламу в конце каждой главы комикса. Данное приложение пару лет назад было доступно на Google Play (платная версия которого и была мной куплена), но было удалено в силу «нарушения авторских прав», после чего ушло в подполье и стало распространятся через сайт разработчика. Увы, достойных альтернатив этому приложению на android и iOS я не нашел, но и смотреть рекламу особо не было желания, тем более я уже покупал версию без рекламы. Сам разработчик почему-то не сделал возможности отключить ее, а на просьбы добавить такую возможность не отозвался. Поэтому пришлось искать альтернативные методы ее отключения. Первое, что пришло в голову, это то, что android-приложения пишутся на java, а значит есть вероятность, что автор не обфусцировал свое приложение и его можно попытаться декомпилировать. Немного подумав, я приступил к работе.

Для начала был загружен сам apk-файл приложения. Затем недолгий поиск по интернету привел меня на сайт http://www.decompileandroid.com/. С его помощью можно было загрузить apk-файл с приложением и на выходе получить набор исходников. Увы, декомпиляция в java-классы происходит не совсем идеально и поэтому восстановить полностью сам проект приложения в IDE(Idea) у меня не получилось, но это позволило проанализировать саму структуру проекта и разобраться как он примерно работает. После проведения анализа, было найдено два перспективных метода в классе BaseReaderFragment.javaplaceAdViewIfNeeded и removeAdViewIfNeeded.

Код метода placeAdViewIfNeeded:

if (adViewPlaced || adView == null) < return; >else

Самое простое, что пришло на ум после чтения кода, это убрать все лишнее, и оставить лишь вызов return;

Но, как уже было сказано, даже если бы я изменил в java-классе что-либо, я бы не смог в итоге скомпилировать приложение в IDE. Поэтому пришлось искать альтернативу. Оказалось, что smali-файлы, которые создаются в процессе декомпиляции, позволяют также после внесения нужных изменений, вновь собрать модифицированное приложение. Увы, сайт, что был приведен выше, позволял лишь получать исходники, но не собирать новые. Поэтому пришлось искать способы сделать это самостоятельно.
Была найдена утилита ApkTools, которая позволяла декомпилировать и компилировать apk-файлы. Кроме того, потребовалась утилита aapt.exe, которая была взята мной из стандартного SDK под андроид в папке android-sdk\build-tools\20.0.0.

Для удобства вызова утилиты из под windows был создан скрипт apktool.bat:

@echo off set PATH=%CD%;%PATH%; java -jar "%~dp0\apktool.jar" %1 %2 %3 %4 %5 %6 %7 %8 %9 

Для декомпиляции приложения были выполнены команды:

apktool if .apk apktool d .apk 

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

.method protected placeAdViewIfNeeded(Landroid/view/ViewGroup;)V .locals 3 .param p1, "layoutAds" # Landroid/view/ViewGroup; .prologue const/4 v2, -0x2 return-void .end method .method protected removeAdViewIfNeeded(Landroid/view/ViewGroup;)V .locals 1 .param p1, "layoutAds" # Landroid/view/ViewGroup; .prologue .line 149 const/16 v0, 0x8 return-void .end method 

Далее пришла очередь сборки apk-файла из исходников.

Сделать это можно cледующей командой:

apktool b

Но это еще не все. Чтобы приложение можно было установить, его нужно было подписать цифровой подписью. Самый простой способ сделать это – это скачать архив в котором находится утилита для подписи приложений и цифровые сертификаты к ней.

Распаковываем архив, выполняем команду:

java -jar signapk.jar certificate.pem key.pk8 .apk .apk 

Полученный apk-файл можно загружать на телефон, чтобы проверить наше модифицированное приложение. Однако в процессе тестирования изменений оказалось, что объявления больше не показываются, однако сама страница для их показа создается, что не очень приятно. Снова был проанализирован код приложения, найден класс BaseSeamlessReaderFragment, а в нем метод appendPages.

В нем было видно, что строчка:

addPage(new MangaPage(i - 1, null, chapteritem, true), false); 

создает дополнительную страницу, помимо тех, что есть в главе манги, с параметром, отвечающим за показ объявлений. Было решено удалить эту строчку и посмотреть результат. Снова заглядываем в аналогичный smali-файл(BaseSeamlessReaderFragment$4) и удаляем строчку:

invoke-virtual , Lorg/mangawatcher/android/fragments/BaseSeamlessReaderFragment;->addPage(Lorg/mangawatcher/android/fragments/BaseSeamlessReaderFragment$MangaPage;Z)V 

Снова проводим сборку apk-файла из исходников и подписываем наше приложение. После установки и тестирования приложения экран с рекламой окончательно исчез, что и было конечной целью.

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

  • android
  • декомпиляция
  • разработка под android
  • reverse engineering
  • Информационная безопасность
  • Разработка под Android

Как из исходного кода сделать приложение

Создание исполняемого файла из одиночного файла .c выглядит довольно просто. Сначала .c-файл компилируется в объектный код (файл .o — «object»), который затем при помощи сборщика (loader; его еще называют линкером — linker) с добавлением системных библиотек превращается собственно в исполняемый файл.

Создание программы из одного исходного файла

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

Создание крупной программы

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

Компиляторы языка Си в Unix обычно называются cc (C Compiler), а зачастую (особенно в Linux) используется т.н. GNU C Compiler — gcc . Компиляторы Си++ аналогично называются c++ и g++ . Сборщики именуются ld , хотя можно для этих целей пользоваться и gcc . Библиотекарь-архиватор — программа ar .

Практически все современные клоны Unix поддерживают также разделяемые библиотеки (именуемые .so (shared object) или .sa (shared archive)), которые подключаются к программе непосредственно перед исполнением (аналогично .dll в Windows). Собственно, большинство библиотек являются именно разделяемыми. Здесь мы разделяемые библиотеки не затрагиваем во-первых для краткости, а во-вторых потому, что обычно при компиляции никакого внешнего отличия между .a и .so нет.

Утилита make

Для чего нужен make

Приведенная в предыдущем разделе картина способна повергнуть в уныние — неужели все эти действия надо выполнять «вручную»?

Естественно, нет — для этого существует утилита make , которая все и делает («make» — дословно «делать»).

Утилита make считывает из специального файла с именем Makefile или makefile в текущей директории инструкции о том, как (при помощи каких команд) компилировать и собирать программы, а также информацию, из каких файлов состоит программа, которую надо «сделать».

Одним из главных достоинств make (чрезвычайно полезным при создании больших программ) является то, что он сравнивает времена модификации файлов, и если, к примеру, файл file1.c новее, чем получаемый из него file1.o , то make поймет, что перекомпилировать надо только его, а остальные — не нужно (если они не изменились).

  • Правила, как из одних файлов создавать другие (например, .o из .c ).
  • Так называемые «зависимости», которые указывают, что, например, исполняемый файл proggie собирается из файлов prg_main.o и prg_funcs.o , а те, в свою очередь, получаются из файлов prg_main.c и prg_funcs.c .
  • Определения переменных, позволяющие делать Makefile более гибкими.

Ниже приведен пример простейшего Makefile (он и используемые файлы .c доступны здесь):

CC= gcc CFLAGS= -c -W -Wall .c.o: $(CC) $(CFLAGS) -o $@ $< all: proggie proggie: prg_main.o prg_funcs.o $(CC) -o proggie prg_main.o prg_funcs.o

Определения переменных. Строки вида " ИМЯ=значение " -- это определения переменных. Для получения значения переменной используется запись " $(ИМЯ) " (знак доллара, а за ним имя переменной в скобках). Переменная может определяться через значения других переменных, например:

Правила. Запись " .c.o: " с последующей командой означает: "для любого файла .c , чтобы из него получить одноименный файл .o , надо выполнить такую-то команду"; в данном случае --

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

Это довольно странное правило является основным источником ошибок и запутанности Makefile'ов -- ведь визуально отличить символ табуляции от цепочки пробелов невозможно. Поэтому, к примеру, редактор Midnight Commander автоматически цветом выделяет строки, начинающиеся с символа табуляции.

Makefile в редакторе MC

Зависимости. Запись вида

означает, что файл proggie зависит от файлов prg_main.o и prg_funcs.o . Файл proggie называется целью (target), а файлы .o -- зависимостями (dependencies).

Несмотря на то, что зависимости по внешнему виду похожи на правила, make их различает.

В принципе в данном Makefile не помешали бы и строки

prog_main.o: prog_main.c prog_funcs.o: prog_funcs.c

но у make хватит интеллекта догадаться об этом самому (исходя из правила " .c.o ").

Более длинные правила и зависимости.

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

Аналогично после зависимости на следующих строках можно указать команды, при помощи которых ее надо "делать". Например,

prog_main.o: prog_main.c $(CC) $(CFLAGS) -D_GNU_SOURCE -o prog_main.o prog_main.c

При этом команды, определяемые в правиле " .c.o " использоваться не будут.

В Linux используется GNU-версия программы make (GNU Make), имеющий более богатый синтаксис (он включает условные конструкции, директиву include для "вставки" других файлов, более гибкий формат определения правил (вида %.c: %.o )). Поэтому многие программы пользуются Makefile'ами именно под GNU Make. В других ОС для вызова GNU Make обычно служит команда " gmake ".

При запуске без параметров make пытается сделать самую первую цель из перечисленных в Makefile. Обычно в качестве первой ставят дополнительную цель " all ", зависящую от всех файлов, которые надо сделать для изготовления программы.

Если же указать в командной строке имя цели, то make выполнит команды, необходимые для этой цели (и, при надобности, команды для изготовления промежуточных целей).

выполнит только команду компиляции файла prog_main.c в prog_main.o , да и то только если файл .c новее чем .o .

Если запустить make с ключом " -n ", то он лишь напечатает на экране команды, которые следует выполнить, не не станет реально их запускать. (Мнемоника для запоминания: " -n " -- "do Nothing" -- "Nичего не делай".)

Ключ " -f " позволяет заставить make читать инструкции из указанного файла, вместо Makefile или makefile , используемых по умолчанию. Пример:

Если при компиляции или сборке возникает ошибка, то make прекращает процесс, не выполняя последующие команды.

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

Кроме того, очень подробная документация (включая введение для начинающих) есть в info-документации на GNU Make, вызываемой командой " info make ", -- там содержится буквально "все, что вы хотели знать о Make, но боялись спросить".

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

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

Но, поскольку разные клоны довольно сильно отличаются (особенно BSD-системы от SystemV), то написать код, который компилировался и работал бы без изменений на большом количестве систем, практически невозможно. Причем, чем больше программа, тем эта задача сложнее.

Поэтому перед компиляцией надо сначала произвести настройку.

  1. Если к дистрибутиву прилагается скрипт configure , то надо его запустить (командой " ./configure ").
  2. Возможно, в Makefile имеется специальная цель " config " -- в таком случае для конфигурирования служит команда " make config ".
  3. В Makefile могут быть разные цели для разных ОС, в таком случае для компиляции под Irix надо будет дать команду типа " make irix ", а под Linux -- " make linux ".

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

Какой из способов используется в конкретной программе -- надо смотреть в прилагаемой документации (т.е. в файлах типа README и INSTALL).

Непосредственно для инсталляции же практически всегда используется специальная цель " install " в Makefile. Т.е. для того, чтобы после компиляции и сборки установить программу, надо дать команду

Для примера рассмотрим компиляцию двух программ -- Wget, использующей первый способ, и NetCat, использующей третий.

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

Компиляция и установка программы Wget

Развернув архив, мы увидим в нем файл INSTALL и скрипт configure , а вот Makefile там нет!

bobby:~/soft% tar xfz ~/wget-1.5.3.tar.gz bobby:~/soft% cd wget-1.5.3/ bobby:~/soft/wget-1.5.3% ls AUTHORS MAILING-LIST aclocal.m4 configure.in src/ COPYING Makefile.in config.guess* doc/ stamp-h.in ChangeLog NEWS config.sub* install-sh* util/ INSTALL README configure* mkinstalldirs* windows/ MACHINES TODO configure.bat po/ bobby:~/soft/wget-1.5.3% _

Как и следовало ожидать, в INSTALL рекомендуют запустить configure , а затем набрать " make ".

В ответ на команду " ./configure " компьютер сообщает, что конфигурирует программу GNU Wget 1.5.3, а затем около минуты печатает список свойств системы, которые он проверяет. В конце он уведомляет, что создает несколько Makefile (в разных поддиректориях).

Набрав теперь " make ", запускаем процесс компиляции и сборки, который занимает некоторое время.

По его окончании можно набрать " make install ". Вот и все!

Компиляция программы NetCat

Первым делом развернем архив:

bobby:~/soft% mkdir netcat bobby:~/soft% cd netcat bobby:~/soft/netcat% tar xfz ~/nc110.tgz bobby:~/soft/netcat% ls Changelog README generic.h netcat.c stupidh* Makefile data/ netcat.blurb scripts/ bobby:~/soft/netcat% _

Из файла README узнаем, что для компиляции надо указать команде make тип ОС. То же увидим, и запустив make без параметров:

bobby:~/soft/netcat% make Usage: make [options] bobby:~/soft/netcat% _

Беглый просмотр Makefile показывает, что в нем есть цель под названием " linux ". Итак,

bobby:~/soft/netcat% make linux make -e nc XFLAGS='-DLINUX' STATIC=-static make[1]: Entering directory `/export/bobby/ivanov/soft/netcat' cc -O -s -DLINUX -static -o nc netcat.c make[1]: Leaving directory `/export/bobby/ivanov/soft/netcat' bobby:~/soft/netcat% ls Changelog README generic.h netcat.blurb scripts/ Makefile data/ nc* netcat.c stupidh* bobby:~/soft/netcat% ls -l nc -rwxr-xr-x 1 ivanov lab5 142668 May 10 18:21 nc* bobby:~/soft/netcat% _

Как мы видим, после компиляции появился исполняемый файл nc . Поскольку цель " install " в Makefile отсутствует, то для установки надо просто скопировать этот файл в общесистемную директорию:

bobby:~/soft/netcat% su Password: bobby:~/soft/netcat# cp nc /usr/local/bin/ bobby:~/soft/netcat# _

Особенности компиляции программ под X-Window

Imakefile и программа xmkmf

К моменту появления системы X-Window проблема различий при компиляции под разные клоны Unix стала уже широко известна, и был разработан способ, позволяющий унифицированно компилировать ПО для X под разными системами.

Идея заключалась в том, чтобы перед компиляцией Makefile автоматически генерировался специальной утилитой xmkmf , "знающей" про специфику конкретной системы, из другого файла, под названием Imakefile. В Imakefile же на некоем специальном языке записывается примерно та же информация, что в Makefile.

Аббревиатура " xmkmf " расшифровывается очень просто -- "MaKe MakeFile" -- "сделай Makefile", а " x " -- префикс, обозначающий принадлежность программы к X-Window.

Хотя замысел был очень хороший, реализация оставляет желать лучшего. Во-первых, язык Imakefile'ов -- не менее "птичий", чем у Makefile, так что людей, умеющих их создавать, еще меньше. Во-вторых, xmkmf берет описание системы из нескольких файлов конфигурации (в глубине директории /usr/X11R6/ ), а они зачастую оказываются несовместимы с конкретным Imakefile, и xmkmf просто завершается с каким-нибудь маловразумительным сообщением об ошибке.

Тем не менее, большинство программ под X-Window поставляются именно с Imakefile.

Пример сборки и установки программы под X-Window

В качестве примера рассмотрим сборку и установку программы XRoach (той самой, что пускает бегать по экрану тараканов). Воспользуемся локальной копией дистрибутива.

Сначала развернем дистрибутив:

bobby:~/soft% tar xfz ~/xroach.tar.gz bobby:~/soft% cd xroach/ viper:~/soft/xroach% ls Imakefile roach060.xbm roach165.xbm roach270.xbm squish.xbm README.linux roach075.xbm roach180.xbm roach285.xbm xroach.a patchlevel.h roach090.xbm roach195.xbm roach300.xbm xroach.c roach000.xbm roach105.xbm roach210.xbm roach315.xbm xroach.man roach015.xbm roach120.xbm roach225.xbm roach330.xbm roach030.xbm roach135.xbm roach240.xbm roach345.xbm roach045.xbm roach150.xbm roach255.xbm roachmap.h bobby:~/soft/xroach% _

Прочтя файл README.linux , мы узнаем лишь, что при компиляции должно быть предупреждение (warning) в строке 373.

Запускаем xmkmf и затем make :

bobby:~/soft/xroach% xmkmf imake -DUseInstalled -I/usr/X11R6/lib/X11/config bobby:~/soft/xroach% make gcc -O2 -fno-strength-reduce -I/usr/X11R6/include -Dlinux -D__i3 86__ -D_POSIX_C_SOURCE=199309L -D_POSIX_SOURCE -D_XOPEN_SOURCE=500L -D _BSD_SOURCE -D_SVID_SOURCE -DFUNCPROTO=15 -DNARROWPROTO -c xroac h.c -o xroach.o xroach.c: In function `FindRootWindow': xroach.c:373: warning: passing arg 9 of `XGetWindowProperty' from inco mpatible pointer type xroach.c:373: warning: passing arg 12 of `XGetWindowProperty' from in compatible pointer type rm -f xroach gcc -o xroach -O2 -fno-strength-reduce -L/usr/X11R6/lib xroach.o -lXext -lX11 -lm bobby:~/soft/xroach% _

Теперь, аналогично обычным программам, делаем " make install ":

bobby:~/soft/xroach% su Password: bobby:~/soft/xroach# make install install -c -s xroach /usr/X11R6/bin/xroach install in . done bobby:~/soft/xroach# _

Единственно что, автор поленился сделать автоматическую установку man-страницы, хотя она и есть. Что ж, не беда -- скопируем ее в нужное место "руками":

bobby:~/soft/xroach# cp xroach.man /usr/X11R6/man/man1/ bobby:~/soft/xroach# _

(Поскольку " make install " установил программу в /usr/X11R6/bin/ , то и man-страницу надо положить "рядом" -- внутри /usr/X11R6/ . А поскольку xroach -- пользовательская программа, то ее man-страница должна лежать в разделе 1 (поддиректория man1/ .)

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

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

Распаковка

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

.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

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *