[ MINIX 3. Портирование POSIX программ
Цилюрик О.И.
Редакция 1.07
от 03.06.2010
Оглавление
Аннотация
Введение
Версии системы
Обозначения в тексте
Компиляция и сборка POSIX программы / проекта
Тестовый проект
Компиляция отдельных программ
Полезные советы относительно компиляции
Оформление собственного проекта Autoconf/Automake
Перенос проекта, подготовленного Autoconf/Automake
Полезные советы конфигурирования
Оформление MINIX пакета
Дополнительные источники информации
Аннотация Описываются некоторые приёмы перенесения проектов GNU и отдельных программ, соответствующих стандартам POSIX, в систему MINIX 3.
Введение Портирование программного обеспечения в MINIX из POSIX совместимых систем (чаще всего из Linux или *BSD) является во многих случаях нетривиальным, но и не невыполнимым. Главная часть работы зачастую заключается в изменениях в Makefile или скриптов сборки. Перекодирование больших частей программного обеспечения требуется только либо для программ, которые частично или полностью выполняются в пространстве ядра, либо для программ, использующих POSIX API, не реализованные в MINIX (например, потоки, и все API вида pthread_*()).
При портировании любой программы в MINIX нам предстоит рассматривать последовательно несколько задачи:
Компиляция и сборка POSIX проекта. На этом этапе программный код, написанный и проверенный для другой POSIX системы, вам предстоит собрать в совершенно не предусмотренной этим кодом среде — операционной системе MINIX.
Оформление MINIX проекта. Теперь, добившись работоспособности программы, вам предстоит оформить (дополнить) программный код так, чтобы его работоспособность могла легко воспроизводиться в любой другой инсталляции MINIX.
Скрипты (утилиты) установки и удаления программных пакетов в системе, такие, как существующие:
packman, binpackage etc., или недостающие, которые нужно дописать.
Последний вопрос — чисто технический, тем более, что он сильно меняется от версии к версии системы. А вот первые 2 вопроса, как 2 последовательные фазы, и будут рассмотрены в дальнейшем тексте. Между этими 2-мя фазами обязательно будет ещё проверка работоспособности, тестирование программы, но это уже совсем не относится непосредственно к предмету нашего рассмотрения.
Версии системы Версии MINIX3 в очень большой мере «волатильны» - разработчики часто вносят существенные изменения, даже не считая должным отражать их даже в MAN страницах. Вся основная часть описания отрабатывалась на стабильной версии 3.1.6 (релиз 6084). В используемой вами версии могут быть, порой, довольно существенные отличия, но основные принципы при этом сохраняются.
Обозначения в тексте В самом тексте, все примеры команд (скопированные с терминала) будет показываться моноширинным шрифтом. Кроме того, в большинстве случаев пользовательский ввод в записи команды будет показан жирным шрифтом, а ответный вывод от системы — обычным. Короткие цитаты из различных источников информации будут показываться курсивом. Также, если любое слово в тексте должно считаться термином в данном контексте: имя или расширение файла, имя переменной, название программного пакета — то термин будет показываться моноширинным шрифтом.
Компиляция и сборка POSIX программы / проекта Эти рекомендации будут служить отправной точкой для разработчиков, желающих портировать некоторое POSIX приложение в MINIX 3. Сложность процесса определяется разнообразием исходных условий задачи, форм, в которых может быть представлен исходный программный код, подлежащий портированию:
это может быть простейшая тестовая программа на языке C, написанная вашим соседом по лестничной клетке, не содержащая в своём составе даже файла сборки Makefile;
это может быть (чаще всего) программный проект, подготовленный к сборке GNU инструментарием Autoconf/Automake;
это может быть просто программный проект, подготовленный к сборке другой технологией (их число постоянно множится), пример такой технологии, достаточно часто уже встречаемой, cmake;
это может быть программный проект (даже весьма объёмный), полностью написанный на скриптовом языке shell, синтаксические детали языков shell (ash, bash, zsh) различаются; кроме того могут различаться файловые пути различных компонент в системе;
это может быть программный проект, написанный на другом языке программирования, отличающемся от C, в этом случае вам придётся проверить наличие такого языкового средства в системе, или установить его (самым ярким примером этого случая является C++, который потребует установки компилятора gcc);
В любом случае, компиляция и сборка чужого программного проекта всегда будет оставаться процессом поисковым, и не подлежит формальному описанию. Имейте при этом себе в виду, что процесс этот может завершиться неудачей, не взирая на любые затраченные усилия (он может просто потенциально не собираться для данной операционной системы). Весь дальнейший текст этого раздела — это только рекомендации, и не более, как вы можете упростить себе жизнь на этом пути.
К этому моменту рассмотрения будем считать, что вы уже скачали архив интересующего вас проекта в архиве форматов *.tgz, *.tar.gz, или *.tar.bz2, и разархивировали его в рабочий каталог.
Тестовый проект.
В качестве тестового проекта, который пройдёт через все разделы описания, я буду рассматривать портирование довольно известного пакета dbug-2.0.0 (http://sourceforge.net/projects/dbug/files/) — объектной библиотеки внутреннего отладчика. В минимально достаточном объёме нам достаточно перенести в наш проект:
Makefile dbug.c dbug.h # make gcc -g -Wall -c -o dbug.o dbug.c LANG=ua; gar -r libdbug.a dbug.o gar: creating libdbug.a Для возможности тестирования того, что мы собрали, добавим к проекту тестовую задачу fact_dbug.c:
#include #include #include #include "dbug.h" unsigned long factorial( int value ) {.
unsigned long res;
DBUG_ENTER( "factorial" );
DBUG_PRINT( "info", ( "Got argument: '%d'", value ) );...
if( 1 == value || 0 == value ) DBUG_RETURN( 1 );
res = value * factorial( value - 1 );
DBUG_RETURN( res );
int main( int argc, char* argv[] ) { register unsigned long result;.
int i;...
DBUG_ENTER( "main" );
DBUG_PROCESS( argv[ 0 ] );
for( i = 1; i < argc && argv[ i ][ 0 ] == '-'; i++ ) { printf( "usage: %s [-#{d|t|O}] \n", argv[ 0 ] );
result = factorial( atoi( argv[ i ] ) );
printf( "%ld\n", result );
DBUG_RETURN( 0 ) Всё, что есть DBUG_* - это и есть макросы пакета dbug, прикомпонованного к тестовой задаче статически (в MINIX 3 никакой иной компоновки не существует). Полный файл сборки Makefile теперь имеет вид :
CC=gcc -g -Wall AR=gar LIST=dbug fact_dbug fact_dbug: fact_dbug.c clean:
rm -f *.o *.a $(LIST).
Всё, проект в смысле законченной задачи выполняющейся в MINIX 3, завершён:
# make gcc -g -Wall -c -o dbug.o dbug.c LANG=ua; gar -r libdbug.a dbug.o gar: creating libdbug.a gcc -g -Wall -o fact_dbug fact_dbug.c dbug.o #./fact_dbug -#t | >factorial | | >factorial | | | >factorial
«