Журнал LinuxFormat - перейти на главную

LXF169:Дис­тро­ст­рой. Сам се­бе ди­ст­ри­бу­тив

Материал из Linuxformat
(Различия между версиями)
Перейти к: навигация, поиск
(Ин­ст­ру­мен­ты сбор­ки)
 

Текущая версия на 09:37, 14 ноября 2018

Crosstool-ng: Ищем ин­ст­ру­мен­та­рий.

Содержание

[править] Ос­но­вы дис­тро­строе­ния. Го­то­вим ин­ст­ру­мен­та­рий для сбор­ки ди­ст­ри­бу­ти­ва

Дмит­рий Куз­не­цов го­то­вит­ся к сбор­ке соб­ст­вен­но­го ди­ст­ри­бу­ти­ва, тща­тель­но под­би­рая ин­ст­ру­мен­ты.

(thumbnail)
Наш эксперт Дмит­рий Куз­не­цов бо­лее 10 лет ве­дет не­рав­ный бой с мон­ст­ра­ми слож­но­сти, хо­тя не­ко­то­рые по­че­му-то их счи­та­ют вет­ря­ны­ми мель­ни­ца­ми.

Ди­ст­ри­бу­ти­в Linux ныне уста­но­вить лег­ко. За пол­ча­са, от­ве­тив на ряд про­стых во­про­сов, лю­бой но­ви­чок по­лу­чает го­то­вую ОС. Она са­ма за­гру­жа­ет­ся, снаб­же­на гра­фи­че­­ским ин­тер­фей­сом поль­зо­ва­те­ля и со­дер­жит со­лид­ный на­бор при­клад­ных про­грамм, рас­ши­ряе­мый несколь­ки­ми дви­жения­ми мы­ши. Это здо­ро­во! Раз­ра­бот­чи­ки ди­ст­ри­бу­ти­вов за­слу­жи­ва­ют са­мой ис­кренней бла­го­дар­но­сти и восхи­щения. Боль­шин­ст­ву поль­зо­ва­те­лей ниче­го сверх то­го и не на­до. Но есть и те, кто хо­чет понимать внут­реннее уст­рой­ст­во сис­те­мы, а не толь­ко по­жи­нать пло­ды ра­бо­ты «чер­ного ящи­ка». Их пыт­ли­вый ум веч­но ста­вит во­про­сы. Как ра­бо­та­ет сис­те­ма? Из ка­ких ком­понен­тов со­сто­ит? В ка­ком порядке они за­пуска­ют­ся при за­груз­ке? Ка­кие из них глав­ные, а ка­кие вто­ро­сте­пен­ные? Как их со­брать из ис­ход­ных ко­дов? Ана­то­мия Linux в об­щих чер­тах осве­ще­на в глав­ной ста­тье но­ме­ра, но тут и це­лой книги бу­дет ма­ло.

Жерт­во­вать глу­би­ной из­ло­жения, говоря о та­ких фун­да­мен­таль­ных про­блемах, бы­ло бы ошиб­кой. Ра­зумнее ог­раничить ши­ри­ну ох­ва­та наи­бо­лее важ­ными во­про­сами – их глу­бо­кое понимание станет проч­ной осно­вой для дальней­ше­го изу­чения. Мы по­про­бу­ем по­стро­ить минималь­ный ди­ст­ри­бу­тив для ар­хи­тек­ту­ры x86_64 и за­пустить его на вир­ту­аль­ной ма­шине KVM. Эти ба­зо­вые знания по­зво­лят чи­та­те­лям ладить с лю­бым ди­ст­ри­бу­ти­вом Linux, а осо­бо неуго­мон­ным – про­дол­жить изыскания са­мим.

[править] Ком­плек­та­ция

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

По­сле вклю­чения пи­тания про­цес­со­ру по­да­ет­ся сиг­нал RESET, чтобы про­цес­со­р уста­но­вил свои ре­ги­ст­ры на передачу управ­ления ко­ду BIOS, за­пи­санному в ПЗУ. BIOS тес­ти­рует и инициа­ли­зирует ап­па­рат­ные уст­ройства, а за­тем про­смат­ри­ва­ет пер­вые (за­гру­зоч­ные) сек­то­ры всех дис­ков, ука­зан­ных в BIOS Setup, для по­ис­ка за­груз­чи­ка ОС. Когда за­груз­чик най­дется, он ско­пи­ру­ет­ся в опе­ра­тив­ную па­мять и на­чи­на­ет вы­пол­нять­ся. Его за­да­чи – най­ти яд­ро Linux, ско­пи­ро­вать его в па­мять и пе­ре­дать ту­да управ­ление. Яд­ро вы­пол­ня­ет свою иници­али­за­цию, мон­ти­ру­ет корневую фай­ло­вую сис­те­му и за­пуска­ет пер­вую поль­зо­ва­тель­скую про­грам­му init – обыч­но это /sbin/init, но в па­ра­мет­рах яд­ра мож­но ука­зать лю­бую дру­гую. Дей­ст­вия init настраиваются в фай­ле /etc/inittab – обыч­но ука­зы­ва­ет­ся за­пуск стар­то­во­го сце­на­рия и команд­ной обо­лоч­ки [shell]. Все, ОС за­гру­же­на и ждет команд поль­зо­ва­те­ля.

Те­перь оче­ви­ден спи­сок необ­хо­ди­мо­го ПО:

» За­груз­чик и яд­ро Linux.

» Init, shell и дру­гие при­клад­ные про­грам­мы.

» Биб­лио­те­ки, необ­хо­ди­мые для при­клад­ных про­грамм. Для боль­шин­ст­ва ути­лит команд­ной стро­ки Linux тре­бу­ет­ся толь­ко стан­дарт­ная биб­лио­те­ка язы­ка C (GNU libc или ее ана­ло­ги).

» Файл /etc/inittab для на­строй­ки init.

» Стар­то­вый сце­на­рий (за­пуска­ет­ся из inittab).

Для дру­гих ар­хи­тек­тур (не x86) про­цесс за­груз­ки от­ли­ча­ет­ся лишь на­чаль­ной ста­ди­ей: до пе­ре­да­чи управ­ления яд­ру Linux. На­при­мер, на встраи­вае­мых плат­фор­мах (ар­хи­тек­ту­ра ARM) час­то ис­поль­зу­ют U-boot. Это спе­ци­аль­ная стар­то­вая сре­да (еще ее на­зы­ва­ют bootstrap-сре­да или за­груз­чик), ко­то­рая вы­пол­ня­ет функ­ции BIOS и за­груз­чи­ка на ПК.

[править] Ин­ст­ру­мен­ты сбор­ки

Ком­плек­та­ция ди­ст­ри­бу­ти­ва оп­ре­де­ле­на. Ис­ход­ные тек­сты ком­понен­тов доступ­ны. Как их со­брать? От­вет вро­де оче­ви­ден: есть же GCC, стан­дарт­ный ком­пи­ля­тор для OC Linux. Вер­но. Но не все зна­ют, что GCC – толь­ко вер­ши­на айс­бер­га. Для ком­пи­ля­ции и генера­ции ис­пол­няе­мо­го ко­да из ис­ход­ных тек­стов его ма­ло, ну­жен це­лый ин­ст­ру­мен­та­рий [англ. toolchain – це­поч­ка ин­ст­ру­мен­тов]. Он со­сто­ит из сле­дую­щих ком­понен­тов:

» GCC (GNU Compiler Collection) – на­бор ком­пи­ля­то­ров (в том чис­ле С и C++).

» Binutils – ас­семб­лер, ком­по­нов­щик и на­бор про­грамм для об­ра­щения с объ­ект­ным ко­дом.

» GNU libc (или ее ана­лог) – стан­дарт­ная биб­лио­те­ка язы­ка С.

» За­го­ло­воч­ные фай­лы яд­ра Linux.

Все эти ин­ст­ру­мен­ты вхо­дят в со­став лю­бо­го ди­ст­ри­бу­ти­ва Linux в го­то­вом к ис­поль­зо­ванию ви­де. Но учти­те, что они со­б­ра­ны с це­лью генери­ро­вать ис­пол­няе­мый код толь­ко для дан­но­го ди­ст­ри­бу­ти­ва и дан­ной ар­хи­тек­ту­ры. То есть с их по­мо­щью мож­но со­брать толь­ко клон ди­ст­ри­бу­ти­ва сво­его ПК. И дво­ич­ная со­вмес­ти­мость бу­дет пре­восход­ная. Кста­ти, в раз­но­сти ин­ст­ру­мен­та­ри­ев и кро­ют­ся корни про­блем дво­ич­ной несо­вмес­ти­мо­сти раз­ных ди­ст­ри­бу­ти­вов Linux. А фа­за Лу­ны, как дума­ют иные, тут ни при чем.

Со­би­рать толь­ко кло­ны неин­те­рес­но, нуж­но до­ко­пать­ся до пер­во­ис­точников. По­хо­же, во­про­сов ста­но­вит­ся все боль­ше. Ес­ли ка­кие-то ком­понен­ты ин­ст­ру­мен­та­рия не уст­раи­ва­ют? Ес­ли нуж­но со­брать ин­ст­ру­мен­та­рий для дру­гой ар­хи­тек­ту­ры (не x86)? Ес­ли на ПК нуж­но соз­дать сре­ду сбор­ки ПО для сво­его смарт­фо­на с ARM про­цес­со­ром? Все это воз­мож­но. Ком­понен­ты ин­ст­ру­мен­та­рия под­дер­жи­ва­ют массу раз­ных ар­хи­тек­тур и име­ют ог­ром­ное ко­ли­че­­ст­во па­ра­мет­ров сбор­ки. Но нуж­но уметь их са­мо­стоя­тель­но со­би­рать из ис­ход­ных ко­дов. Конеч­но, это непро­стая за­да­ча, ко­то­рая тре­бу­ет вре­мени, опы­та и спе­ци­аль­ных знаний.

К сча­стью, есть замечатель­ный про­ект – crosstool-ng. С его помощью лег­ко за­дать нуж­ные па­ра­мет­ры ин­ст­ру­мен­та­рия, за­гру­зить из Ин­тернета ис­ход­ные ко­ды его ком­понен­тов и ав­то­ма­ти­че­­ски их со­брать. Кроме того, crosstool-ng ве­дет под­роб­ный жур­нал вы­полнен­ных команд, ана­ли­зируя который, можно детально ра­зо­брать­ся в про­цес­се сбор­ки.

[править] Crosstool-ng: уста­но­вка

За­гру­зим ар­хив ис­ход­ных ко­дов сrosstool-ng с сай­та про­ек­та:

wget -nd -P /root/work/download crosstool-ng.org/download/crosstool-ng/crosstool-ng-1.16.0.tar.bz2

Он име­ет фор­мат tar.bz2, тра­ди­ци­он­ный для ми­ра Linux, по­это­му лег­ко рас­па­ко­вы­ва­ет­ся в ра­бо­чий ка­та­лог:

tar -C /root/work/src -xjvf /root/work/download/crosstool-ng-1.16.0.tar.bz2

Для ра­бо­ты crosstool-ng тре­бу­ет­ся до­пол­ни­тель­ное ПО – за­ви­си­мо­сти. Ус­та­но­вить его (ес­ли это не сде­ла­но ра­нее) мож­но так:

apt-get install bison flex gperf texinfo gawk libtool automake libncurses5-dev g++ subversion

Сбор­ка про­ек­та то­же не от­ли­ча­ет­ся особой ори­ги­наль­но­стью, за вычетом клю­ча enable-local, ко­то­рым нам сей­час удоб­но восполь­зо­вать­ся. Он ин­фор­ми­ру­ет crosstool-ng, что поль­зо­ва­тель не намерен уста­нав­ли­вать его в сис­те­му, а бу­дет за­пускать локаль­но из ка­та­ло­га с его ис­ход­ны­ми ко­да­ми. Та­ким образом, для уда­ления crosstool-ng доста­точ­но бу­дет про­сто уда­лить этот ка­та­лог.

cd /root/work/src/crosstool-ng-1.16.0/

./configure --enable-local

make

[править] Сбор­ка ин­ст­ру­мен­та­рия

Итак, crosstool-ng со­б­ран и го­тов к ра­бо­те. Мож­но со­би­рать ин­ст­ру­мен­та­рий. Сбор­ка ин­ст­ру­мен­та­рия со­сто­ит из двух эта­пов:

1 Под­го­тов­ка фай­ла .config. Это – кон­фи­гу­ра­ция со­би­рае­мо­го ин­ст­ру­мен­та­рия.

2 За­пуск сбор­ки по соз­дан­ной кон­фи­гу­ра­ции.

Файл .config по­хож на тот, что ис­поль­зу­ет­ся ядром Linux. Есть и ана­ло­гич­ная ин­те­рак­тив­ная сис­те­ма кон­фи­гу­ри­ро­вания, за­пустив ко­то­рую, мож­но соз­дать кон­фи­гу­ра­цию с ну­ля или от­кор­рек­ти­ро­вать уже су­ще­ст­вую­щую. По умол­чанию счи­та­ет­ся, что .config на­хо­дит­ся в те­ку­щем ка­та­ло­ге. К сча­стью, в со­став crosstool-ng (под­ка­та­лог samples) вхо­дит мно­же­ст­во при­ме­ров кон­фи­гу­ра­ций, ко­то­рые слу­жат хо­ро­шей осно­вой для по­строения сво­их собственных. Они на­столь­ко раз­но­об­раз­ны, что час­то доста­точ­но из­менить все­го лишь несколь­ко па­ра­мет­ров.

Про­ме­жу­точ­ные ре­зуль­та­ты сво­ей ра­бо­ты (ис­ход­ный код ком­понен­тов, объ­ек­тые фай­лы, жур­нал сбор­ки и т. д.) crosstool-ng хранит в те­ку­щем ка­та­ло­ге. По­это­му для сбор­ки ка­ж­до­го ин­ст­ру­мен­та­рия удоб­но соз­да­вать от­дель­ный ка­та­лог, де­лать его те­ку­щим и все ко­ман­ды за­пускать из него:

mkdir -p /root/work/files/toolchain/build

cd /root/work/files/toolchain/build

Сре­ди доступ­ных при­ме­ров лег­ко най­ти под­хо­дя­щий для дан­но­го слу­чая: /work/src/crosstool-ng-1.16.0/samples/x86_64-unknown-linux-gnu/crosstool.config. Что­бы им восполь­зо­вать­ся, нуж­но ско­пи­ро­вать его в ра­бо­чий ка­та­лог под именем .config и за­пустить ин­те­рак­тив­ную сис­те­му кон­фи­гу­ри­ро­вания:

cp ../../../src/crosstool-ng-1.16.0/samples/x86_64-unknown-linux-gnu/crosstool.config ./.config

/root/work/src/crosstool-ng-1.16.0/ct-ng menuconfig

Она по­ка­зы­ва­ет па­ра­мет­ры ин­ст­ру­мен­та­рия в ие­рар­хи­че­­ском ви­де. Мно­гие из них снаб­же­ны спра­воч­ной ин­фор­ма­ци­ей (кноп­ка Help внизу эк­ра­на). Это удоб­но для изу­чения: так бы­ст­рее ра­зо­брать­ся, что в дан­ной кон­фи­гу­ра­ции надо из­менить.

» Раз­дел Paths and misc options [Пу­ти и об­щие на­строй­ки всей сис­те­мы]

Ус­та­но­вить Try features marking EXPERIMENTAL. Это даст воз­мож­ность вы­брать но­вейшие вер­сии ком­понен­тов ин­ст­ру­мен­та­рия.

Ука­зать в Local tarballs directory путь /root/work/download. Там бу­дут со­хранены за­гру­жен­ные ар­хи­вы с ис­ход­ны­ми ко­да­ми. При по­втор­ной сбор­ке они не бу­дут за­гру­жать­ся сно­ва.

Ука­зать в Prefix directory путь /root/work/files/toolchain/result. Там бу­дет со­хранен со­б­ран­ный ин­ст­ру­мен­та­рий.

» Раз­дел Target options [Па­ра­мет­ры це­ле­вой ар­хи­тек­ту­ры]

Здесь все пра­виль­но. В Target architecture уста­нов­ле­но зна­чение x86, а в Bitness – 64-bit, как раз на­ш слу­чай. Но бо­гат­ст­во вы­бо­ра ар­хи­тек­тур впе­чат­ля­ет: де­вять штук! На­при­мер, мож­но вы­брать arm и по­лу­чить ин­ст­ру­мен­та­рий для сбор­ки ПО под смарт­фо­ны.

» Раз­дел вер­сий ком­понен­тов

Что-то они ста­ро­ва­ты. По­жа­луй, сто­ит вы­брать по­но­вее. (На­при­мер, мож­но ори­ен­ти­ро­вать­ся на Ubuntu 12.04 LTS, где пол­ный спи­сок уста­нов­лен­но­го ПО мож­но по­лу­чить командой dpkg -l.)

Пройдя по подпунктам меню, выберем вер­сию яд­ра Linux: Operating system > Linux kernel version – укажем 3.2.25.

Теперь аналогичным образом выберем вер­сию binutils: Binary utilities > binutils version – нас интересует 2.22 (EXPERIMENTAL).

Нам понадобится определенная вер­сия GCC: C compiler > gcc version – выберем 4.6.3. За­од­но в том же раз­де­ле C compiler нуж­но от­клю­чить под­держ­ку язы­ков Fortran и Java (раз уж мы решили собирать минимальный дистрибутив, обойдемся без излишеств).

Далее озаботимся выбором биб­лио­те­ки язы­ка С. Отме­тим, что су­ще­ст­ву­ет несколь­ко ана­ло­гов этой биб­лио­те­ки. Конеч­но, GNU C library (glibc) – это клас­си­ка. Но не все ею до­воль­ны, и та­ких с ка­ж­дым го­дом все боль­ше и боль­ше: есть у ста­руш­ки ряд про­блем. По­это­му раз­ра­бот­чи­ки неко­то­рых ди­ст­ри­бу­ти­вов ре­ши­ли сменить glibc на один из ее ана­ло­гов. Скажем, в Ubuntu применяют Embedded GLIBC (eglibc). Итак, идем по подпунктам: C-library > C library – выберем eglibc, C-library > eglibc version – выберем 2.15.

Вер­сии со­пут­ст­вую­щих биб­лио­тек (ма­те­ма­ти­че­­ские биб­лио­те­ки, ис­поль­зуе­мые в GCC) указываются в раз­де­ле Companion libraries: GMP version – 5.0.2, MPFR version – 3.1.0, PPL version – 0.11.2, CLog/ppl version – 0.15.11, MPC version – 0.9.

» Раз­дел Debug facilities Для простоты луч­ше от­клю­чить тут все.

Ос­та­лось за­крыть сис­те­му кон­фи­гу­ри­ро­вания (два­ж­ды на­жав Esc), со­гла­сив­шись с со­хранением из­менений в фай­ле .config. Кон­фи­гу­ра­ция ин­ст­ру­мен­та­рия го­то­ва. Мож­но за­пускать сбор­ку:

/root/work/src/crosstool-ng-1.16.0/ct-ng build

На это потребуется несколь­ко де­сят­ков ми­нут. crosstool-ng са­мостоятельно за­гру­зит ис­ход­ный код необ­хо­ди­мых ком­понен­тов, со­бе­рет их и пре­доста­вит под­роб­ный от­чет о про­де­лан­ной ра­бо­те (build.log в те­ку­щем ка­та­ло­ге).

Ура, наш ин­ст­ру­мен­та­рий под­го­тов­лен! Те­перь мож­но со­би­рать ком­понен­ты ди­ст­ри­бу­ти­ва из ис­ход­ных ко­дов – чем мы и зай­мем­ся в сле­дую­щий раз. |

Персональные инструменты
купить
подписаться
Яндекс.Метрика