Armadilloが動作する仕組み

前章で実際にArmadilloを動かしてみて、Armadilloとはどのようなコンピューターなのか、大体のイメージが掴めたと思います。この章では、Armadilloがどのようなソフトウェアで構成されていて、それらがどのように動いているのか、その仕組みを詳しく説明していきます。

6.1. ソフトウェア構成

Armadilloは、以下のソフトウェアによって動作します。

6.1.1. ブートローダー

ブートローダーは、電源投入後、最初に動作するソフトウェアです。 Armadillo-600シリーズではU-bootブートローダー(以降、単にU-bootと記述します)を使用します。

U-bootは、二つの動作モードを持っています。一つは、オートブートモードです。オートブートモードでは、カーネルイメージをブートデバイス^[36]から読み出し、メモリに展開してからカーネルに制御を移します。この動作は、「ブートローダーが行う処理」で詳しく説明します。

もう一つの動作モードは保守モードで、コンソールにプロンプトを表示し、ユーザーが入力したコマンドに応じてU-Bootの環境変数の変更などを行えます。

6.1.2. Linuxカーネル

Linuxカーネルは、プロセス管理(スケジューリング)、時間管理、メモリ管理、デバイスドライバ、プロトコルスタック、ファイルシステムなどのOSとしてのコア機能を提供します。 Armadillo-600シリーズでは、標準のカーネルとして Linux を使用します。

Linuxカーネルの初期化処理については、「カーネルの初期化処理」で詳しく説明します。

6.1.3. ユーザーランド

ユーザーランドとは、アプリケーションプログラムやライブラリ、設定ファイル、データファイル、デバイスファイルなどLinuxシステムが動作する上で必要なカーネル以外のものをいいます。

	カーネルとユーザーランドとのインターフェース
	Linuxカーネルは、ユーザーランドで動作するプログラムとの唯一のAPI(Application Program Interface)として、システムコールを提供します。ユーザーランドのプログラムは、必ずシステムコールを通してカーネルの機能を呼び出します。

Linuxシステムでは、ユーザーランドのファイルとディレクトリ^[37]同士の位置関係を階層的な木構造として表現します。ファイルとディレクトリの木構造をファイルシステムといいます。また、木構造の最上位に位置するディレクトリをルートディレクトリといいます。全てのファイルはルートディレクトリから辿ることができます。

ファイルシステムは、通常、ストレージデバイス^[38]に書き込まれて使用されます。ストレージデバイスをファイルシステムと関連付け、システムから使用できるようにすることを、「マウントする」といいます。 Linuxシステムでは、任意のディレクトリにデバイスをマウントすることができます。特に、ルートディレクトリにマウントされたファイルシステムを、ルートファイルシステムといいます。

Windowsのファイルシステムとの違い

Windowsも階層的なファイル構造を持っていますが、Linuxシステムとは決定的な違いがあります。それは、Linuxシステムのファイルシステムにはドライブという考え方がないことです。

Windowsでは複数のストレージデバイスがある場合、デバイスごとにドライブという形で区別し、別々の階層構造を持ちます。一方で、Linuxシステムでは、複数のデバイスがある場合でも、ルートディレクトリから連なる一つの階層構造として表現します。つまり、USBメモリを/mnt/usbディレクトリにマウントし、SDカードを/mnt/usb/sdディレクトリにマウントするといったことができます。デバイスがどれだけ増えようとも、必ずルートディレクトリから辿ることができます。

Armadillo-600シリーズでは、ユーザーランドの標準ルートファイルシステムとして、Debian 9(stretch)を採用しています。

6.2. 起動の仕組み

本章では、標準状態のArmadilloに電源を投入してから、ログイン画面が表示されるまでの起動シーケンスを詳しく説明します。

大まかな起動の流れは、以下のようになります。

ブートローダーが行う処理
1. ブートローダが起動し最低限のハードウェア初期化を行う
2. カーネルイメージをメモリにロードする
3. ブートローダーを抜けて、カーネルに実行を移す
カーネルの初期化処理
1. カーネルが様々なコアやデバイスドライバの初期化処理をおこなう
2. ルートファイルシステムをマウントする
3. カーネルがユーザーランドのinitというアプリケーションプログラムを実行する
ユーザーランドの初期化処理
1. systemdがシステム初期化処理を実行する
2. systemdがsystemd-logind.serviceを起動する
3. systemdがserial-getty@ttymxc0.serviceを起動する
4. systemd-logindがログイン画面を表示する

6.2.1. ブートローダーが行う処理

Armadilloシリーズは、汎用CPUボードという性格上、ユーザーが書き換え可能なフラッシュメモリを搭載しています。

Armadillo-640では、ジャンパの設定を変更することで、microSDカードとeMMCのどちらからブートローダーを起動するのか選択できます。ユーザーが操作を誤ってeMMCの内容を消去してしまっても、microSDカードからブートローダーを起動することで復旧が可能です。

表6.1 ジャンパの設定と起動デバイス

JP1	JP2	起動デバイス
オープン	ショート	eMMC
ショート	ショート	microSD

	ジャンパのオープン、ショートとは
	「オープン」とはジャンパピンにジャンパソケットを接続していない状態です。「ショート」とはジャンパピンにジャンパソケットを接続している状態です。

起動したU-bootは、最低限のハードウェアの初期化を行った後、自分自身をメモリ(RAM)にコピーします。

その後の動作は、スライドスイッチの設定によって決定されます。スライドスイッチを、図6.1「スライドスイッチの設定」の 1 側に設定しておくと保守モード、2 側に設定しておくとオートブートモードとなります。

図6.1 スライドスイッチの設定

: ブートローダーは保守モードになります。保守モードでは、ブートローダーのコマンドプロンプトが起動します。
: ブートローダーはオートブートモードになります。オートブートモードでは、ブートローダーのコマンドプロンプトが表示されず、OSを自動起動します。

6.2.1.1. 保守モード

スライドスイッチを、図6.1「スライドスイッチの設定」の 1 側に設定した状態で起動すると、U-Bootは保守モードとなります。保守モードの場合、U-Bootは、コンソールにプロンプトを表示してコマンド入力待ち状態となります。保守モードでは、U-Bootの環境変数の変更などを行うことができます。

boot コマンドを実行することで、U-Bootはカーネルを起動するための処理を開始します。

参考として、図6.2「U-boot保守モード時の表示」に保守モード起動時のシリアルコンソールへの表示を示します。

U-Boot 2018.03-at4 (Dec 26 2018 - 19:21:13 +0900)

CPU:   Freescale i.MX6ULL rev1.0 at 396 MHz
Reset cause: POR
I2C:   ready
DRAM:  512 MiB
MMC:   FSL_SDHC: 0, FSL_SDHC: 1
Loading Environment from MMC... OK
In:    serial
Out:   serial
Err:   serial
PMIC: PFUZE3000 DEV_ID=0x30 REV_ID=0x11
Net:   FEC
=>

図6.2 U-boot保守モード時の表示

6.2.1.2. オートブートモード

スライドスイッチを、図6.1「スライドスイッチの設定」の 2 側に設定した状態で起動すると、U-Bootはオートブートモードとなります。これが通常運用での設定です。オートブートモードの場合、U-Bootは、コマンド入力待ち状態になることなく、自動的にカーネルを起動するための処理を開始します。

6.2.1.3. Linuxカーネルのブート

次にU-Bootは、環境変数で設定されたストレージデバイスからLinuxカーネルイメージとDTB(Device Tree Blob)をメモリにロードします。

Device Treeは、ハードウェア情報を記述したデータ構造体です。ハードウェアの差分をDevice Treeに記述することによって、1つのLinuxカーネルイメージを複数のハードウェアで利用することができるようになります。

DTB(Device Tree Blob)は、Device Tree Source(Device Treeを記述したソースファイル)をビルドして生成されるバイナリファイルです。

その後、ブートローダーを抜け、カーネルの開始番地へ実行を移します。この一連の処理を、Linuxカーネルをブートすると表現します。

U-BootがLinuxカーネルをブートするときの、コンソールへの出力を図6.3「U-Bootオートブートモード時の表示」に示します。

U-Boot 2018.03-at4 (Dec 26 2018 - 19:21:13 +0900)  

CPU:   Freescale i.MX6ULL rev1.0 at 396 MHz
Reset cause: POR
I2C:   ready
DRAM:  512 MiB
MMC:   FSL_SDHC: 0, FSL_SDHC: 1
Loading Environment from MMC... OK
In:    serial
Out:   serial
Err:   serial
PMIC: PFUZE3000 DEV_ID=0x30 REV_ID=0x11
Net:   FEC
Hit any key to stop autoboot:  0
6105312 bytes read in 194 ms (30 MiB/s)
27015 bytes read in 54 ms (488.3 KiB/s)
## Booting kernel from Legacy Image at 82000000 ...  
   Image Name:   Linux-4.14-at11
   Image Type:   ARM Linux Kernel Image (uncompressed)

   Data Size:    6105248 Bytes = 5.8 MiB
   Load Address: 82000000
   Entry Point:  82000000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 83000000  
   Booting using the fdt blob at 0x83000000
   Loading Kernel Image ... OK
   Loading Device Tree to 9eefc000, end 9ef05986 ... OK

Starting kernel ...

[    0.000000] Booting Linux on physical CPU 0x0  
[    0.000000] Linux version 4.14-at11 (atmark@atde7) (gcc version 6.3.0 2017051
6 (Debian 6.3.0-18)) #1 Tue Jan 29 10:11:05 JST 2019
[    0.000000] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c53c7d
[    0.000000] CPU: div instructions available: patching division code
:
:
:

図6.3 U-Bootオートブートモード時の表示

	U-Bootはシリアルの初期化が完了すると自身のバージョンを表示します。
	この行から数行に渡って、ロードされたカーネルの情報を表示されます。
	この行から数行に渡って、ロードされたDevice Tree Blobの情報を表示します。
	この行以降は、カーネルが表示しています。

6.2.2. カーネルの初期化処理

ブートローダーから実行を移されると、ようやくLinuxカーネルが動作を開始します。

Armadilloのカーネル起動ログの例として、Armadillo-640の起動ログを図6.4「Armadillo-640カーネルブートログ」に示します。

[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 4.14-at11 (atmark@atde7) (gcc version 6.3.0 2017051
6 (Debian 6.3.0-18)) #1 Tue Jan 29 10:11:05 JST 2019
[    0.000000] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c53c7d
[    0.000000] CPU: div instructions available: patching division code
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instructio
n cache
[    0.000000] OF: fdt: Machine model: Atmark Techno Armadillo-640
[    0.000000] Memory policy: Data cache writeback
[    0.000000] cma: Reserved 16 MiB at 0x9f000000
[    0.000000] CPU: All CPU(s) started in SVC mode.
[    0.000000] Built 1 zonelists, mobility grouping on.  Total pages: 129920  
[    0.000000] Kernel command line: root=/dev/mmcblk0p2 rootwait  
[    0.000000] PID hash table entries: 2048 (order: 1, 8192 bytes)
[    0.000000] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
[    0.000000] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
[    0.000000] Memory: 491980K/524288K available (5120K kernel code, 227K rwdata
, 1156K rodata, 3072K init, 230K bss, 15924K reserved, 16384K cma-reserved)
[    0.000000] Virtual kernel memory layout:
[    0.000000]     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
[    0.000000]     fixmap  : 0xffc00000 - 0xfff00000   (3072 kB)
[    0.000000]     vmalloc : 0xe0800000 - 0xff800000   ( 496 MB)
[    0.000000]     lowmem  : 0xc0000000 - 0xe0000000   ( 512 MB)
[    0.000000]       .text : 0xc0008000 - 0xc0600000   (6112 kB)
[    0.000000]       .init : 0xc0800000 - 0xc0b00000   (3072 kB)
[    0.000000]       .data : 0xc0b00000 - 0xc0b38e60   ( 228 kB)
[    0.000000]        .bss : 0xc0b3dac8 - 0xc0b77644   ( 231 kB)
[    0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
[    0.000000] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
[    0.000000] Switching to timer-based delay loop, resolution 41ns  
:
各デバイスやカーネル内部の初期化処理
:
[    2.194104] mmcblk0: mmc0:0001 Q2J55L 3.53 GiB
[    2.203781] mmcblk0boot0: mmc0:0001 Q2J55L partition 1 2.00 MiB
[    2.214910] mmcblk0boot1: mmc0:0001 Q2J55L partition 2 2.00 MiB
[    2.226019] mmcblk0gp0: mmc0:0001 Q2J55L partition 4 8.00 MiB
[    2.237064] mmcblk0gp1: mmc0:0001 Q2J55L partition 5 8.00 MiB
[    2.247819] mmcblk0gp2: mmc0:0001 Q2J55L partition 6 8.00 MiB
[    2.258427] mmcblk0gp3: mmc0:0001 Q2J55L partition 7 8.00 MiB
[    2.268840] mmcblk0rpmb: mmc0:0001 Q2J55L partition 3 4.00 MiB
[    2.285905]  mmcblk0: p1 p2 p3  
[    2.296675] input: gpio-keys as /devices/soc0/gpio-keys/input/input0
[    2.308365] snvs_rtc 20cc000.snvs:snvs-rtc-lp: setting system clock to 1970-0
1-01 00:00:00 UTC (0)
[    2.326849] 5V: disabling
[    2.338196] Warning: unable to open an initial console.
[    2.353434] Freeing unused kernel memory: 3072K
[    2.510160] systemd-udevd[74]: starting version 215
[    2.529550] random: systemd-udevd: uninitialized urandom read (16 bytes read)
[    3.730124] EXT4-fs (mmcblk0p2): mounted filesystem with ordered data mode. Opts: (null)  
[    4.102740] systemd[1]: System time before build time, advancing clock.
[    4.132433] random: systemd: uninitialized urandom read (16 bytes read)
[    4.147338] random: systemd: uninitialized urandom read (16 bytes read)
[    4.166155] systemd[1]: systemd 232 running in system mode. (+PAM +AUDIT +SEL
INUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +
XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN)
[    4.200049] systemd[1]: Detected architecture arm.

Welcome to Debian GNU/Linux 9 (stretch)!

図6.4 Armadillo-640カーネルブートログ

	ブートローダーから実行が移ると、カーネルはまず自身のバージョン、CPUアーキテクチャ、マシン名、メモリの状態などを表示します。
	カーネルパラメータは、「root=/dev/mmcblk0p2 rootwait」が使用されています。
	ここから、各デバイスやカーネル内部の初期化処理が始まります。
	eMMCの第1から第3パーティションが認識されています。
	eMMCの第2パーティションをマウントしています。

6.2.3. ユーザーランドの初期化処理

カーネルは、初期化処理が終えた後、 initramfs を一時的なルートファイルシステムとしてマウントし、initramfs 上のルートディレクトリにあるinitを実行します。

initramfsのinitは、procfs ^[39]やsysfsのマウントや、systemd-udevd の起動などを行います。その後、/dev/mmcblk0p2^[40](eMMCの第2パーティション)を本当のルートファイルシステムとしてマウントし、/sbin/init を実行します。

Armadillo-640(systemd を使用するユーザーランド)では、/sbin/initは/lib/systemd/systemdへのシンボリックリンクとなっており、実際にはsystemdというアプリケーションプログラムが実行されます。

起動時の処理状況を表示するシステムコンソールには、/dev/console を使用します。 /dev/consoleの実体は、Device Treeの/chosen/stdout-pathで指定したデバイスがデフォルトとして使用されます。このデバイスは、カーネルパラメータのconsoleオプションを指定することで変更することができます。図6.4「Armadillo-640カーネルブートログ」で示したように、Armadillo-640では標準ではconsoleが指定されていません。 Armadillo-640の標準イメージでは、/chosen/stdout-pathに UART1 (/dev/ttymxc0) が指定されているため、/dev/ttymxc0 がシステムコンソールとして使われます。

Systemdの概要

SystemdとはLinuxのシステム管理デーモンの一つです。高速なシステム起動/終了や設定ファイルによるシステム管理の共通化、柔軟なプロセス起動を行うことができます。

Linuxの起動を行う処理は今までSysVinitが広く用いられてきました。しかし、並列処理ができない事や、タイマー起動やプロセス起動を行う事ができず、柔軟な起動を行うことができないという問題を抱えていました。この問題を解決するためにSystemdが登場し、多くのLinuxディストリビューションで採用されるようになりました。

Debian GNU/Linuxでは、Debian 8.0 コードネーム: jessieから、デフォルトのシステム管理デーモンにSystemdが使われています。

Systemdでは、プロセスの起動やファイルシステムのマウントなどの処理を "Unit" という単位で管理します。あるUnitが起動した後に起動する、あるUnitと同時に起動する、など細かな制御が可能です。

Systemdはまず、Systemd unit generators(もしくは単にGenerators)と呼ばれるプログラム群^[41]を実行します。 Armadillo-640ではこれらのプログラムは /lib/systemd/system-generators ディレクトリに配置されています。

表6.2 Systemd unit generators

名称	説明
`systemd-cryptsetup-generator`	`/etc/crypttab` を元に Unit を生成するジェネレータ
`systemd-debug-generator`	ランタイムデバッグシェルを有効にし、起動時に特定のユニットをマスクするためのジェネレータ
`systemd-fstab-generator`	`/etc/fstab` を元に Unit ^[a]を生成するジェネレータ
`systemd-getty-generator`	カーネルコンソールを使用する serial-getty@.service Unit ^[b]を自動的に生成するジェネレータ
`systemd-gpt-auto-generator`	GPTパーティションタイプのGUIDに基づいて、ルートパーティション、 `/home` パーティション、および `/srv` パーティションを自動的に検出してマウントし、スワップパーティションを検出して有効にするジェネレータ
`systemd-hibernate-resume-generator`	カーネルパラメータ resume= の値に従って systemd-hibernate-resume@.service Unit を生成するジェネレータ
`systemd-rc-local-generator`	`/etc/rc.local` ^[c]を起動時に、 `/usr/sbin/halt` をシャットダウン時に実行するようにするためジェネレータ
`systemd-system-update-generator`	`/system-update` が存在する場合に、起動プロセスを `system-update.target` に自動的にリダイレクトするジェネレータ
`systemd-sysv-generator`	SysV init のスクリプトをSystemd上で実行するための Unit を自動的に生成するジェネレータ
^[a]標準状態のArmadillo-640では、-.mount と opt-license.mountが生成されます。 ^[b]標準状態のArmadillo-640では、serial-getty@ttymxc0.serviceが生成されます。 ^[c]標準状態のArmadillo-640では、 `rc-local.service` が生成されます。

次に Systemd は、すべてのUnitファイルを読み込み、各Unitの依存関係にしたがって各起動処理を行います。この時に、serial-getty@ttymxc0.service および systemd-logind.service が起動され、systemd-logind によってログイン画面が表示されます。

Systemd が起動した Unit の順番は systemd-analyze コマンドで調べることができます。

次のように systemd-analyze に plot 引数を付けて実行すると、各Unitの起動順序、起動時間などがわかる画像ファイル(SVG形式)が生成されます。

[armadillo ~]# systemd-analyze plot > /home/atmark/systemd-analyze.prot.svg

この画像ファイルをATDEで表示するには eog コマンドを実行します。なお、SVG形式の画像ファイルはFirefox などのWebブラウザでも表示することができます。

[ATDE ~]$ eog systemd-analyze.prot.svg

6.3. ルートファイルシステムのディレクトリ構成

Linuxシステムでのディレクトリ構成には、デファクトスタンダード(事実上の標準)となっている構成があります。それぞれのディレクトリに何を格納するかということも、慣習的に決まっています。それぞれのディレクトリには特定の役割がありますので、それを理解することで、ファイルを探す場合にどのディレクトリを探せばよいか、また、ファイルを追加する場合にどのディレクトリに置けば適切かということが分かります。

ディレクトリ構成の標準規格

ディレクトリ構成の標準規格としてFHS(Filesystem Hierarchy Standard : ファイルシステム階層標準)があります。

すべてのLinuxシステムがこの標準に従っているわけではありませんが、特別な理由がない限り、FHSに従ったディレクトリ構成とするのが望ましいでしょう。

Armadillo-600シリーズのルートファイルシステムの主なディレクトリの構成は、以下のようになっています。

表6.3 ディレクトリ構成

ディレクトリ	ディレクトリの内容
/	ルートディレクトリ、ルートファイルシステムのマウントポイント
/bin	基本的なユーザーコマンドの実行ファイル
/boot	起動に必要なファイル
/dev	デバイスファイル
/etc	設定ファイル
/home	ホームディレクトリ
/home/atmark	atmarkユーザーのホームディレクトリ
/lib	基本的なライブラリ
/media	CD-ROMやUSBメモリなどのリムーバブルメディアのマウントポイント
/mnt	一時的にマウントするファイルシステムのマウントポイント
/opt	サードパーティが提供する追加データ・アプリケーション
/opt/license	Armadilloのライセンス情報
/proc	procfsのマウントポイント(プロセス情報)
/root	rootユーザーのホームディレクトリ
/run	再起動後に保持されない揮発性のランタイムデータ
/sbin	基本的なシステム管理用コマンドの実行ファイル
/srv	システム上で運用されているサーバが使うデータを格納するディレクトリ
/sys	sysfsのマウントポイント(システム情報)
/tmp	一時的なファイル
/usr	ユーザー共有情報ファイル
/usr/bin	必須でないユーザーコマンドの実行ファイル
/usr/sbin	必須でないシステム管理者用コマンドの実行ファイル
/usr/lib	必須でないライブラリ
/var	頻繁に更新されるファイル
/var/log	ログが保存されるディレクトリ

6.3.1. 実行ファイル

アプリケーションの実行ファイルは、/bin、/usr/bin、/sbin、/usr/sbinディレクトリに置かれます。

これらのディレクトリ内にあるファイルが、シェルでコマンドを入力したときに検索されます。そしてコマンドと同じファイル名のファイルがこれらのディレクトリに合った場合、そのファイルが実行されます。

6.3.2. ホームディレクトリ

ユーザーごとのホームディレクトリは/homeディレクトリに用意されています。

Armadillo-600シリーズでは、atmark ディレクトリがあります。 rootユーザーでログインした場合のホームディレクトリは、/rootディレクトリになります。

6.3.3. ライブラリ

ライブラリファイルは/libまたは/usr/libディレクトリに置かれます。共有ライブラリを使用するプログラムを実行する場合は、これらのディレクトリ内に共有ライブラリを置いておく必要があります^[42]。

6.3.4. デバイスファイル

/devディレクトリには、デバイスファイルが置かれます。

デバイスファイルは、デバイスを仮想的にファイルとして表したものです。デバイスファイルに対して操作を実行することにより、デバイスを制御することができます。

例として、Armadillo-640では、/dev/ttymxc2はCON3/CON4のシリアルインターフェースのシリアルデバイスをファイルとして表したものです。 /dev/ttymxc2に対してデータの読み書きをすることで、シリアルデバイスからデータを受信/送信することができます。

6.3.5. プロセス、システムの状態

/proc、/sysディレクトリ内のファイルを操作することで、プロセス、システムの状態を参照、変更することができます。

/procにはprocfs、/sysにはsysfsがマウントされています。 procfs、sysfsはカーネル内部のデータ構造にアクセスすることができる機能を提供する仮想的なファイルシステムです。

6.3.6. ログ

カーネルメッセージやアプリケーションの動作ログなどは/var/logディレクトリに保存します。

6.3.7. 設定ファイル

設定ファイルは、/etcに置かれます。

^[36]標準設定の場合は、eMMCメモリです。Armadillo-600シリーズではmicroSDも指定可能です

^[37]Windowsでのフォルダと同様の概念です。

^[38]HDD(ハードディスクドライブ)やUSBメモリなど

^[39]仮想ファイルシステムと呼ばれるもので、カーネル内部の状態がファイル内容に動的に反映されます。

^[40]このデバイスは、カーネルパラメータの root に指定されています。

^[41]Generatorsは Unitの動的生成やUnitファイルへのシンボリックリンクの生成を行います。

^[42]LD_LIBRARY_PATH環境変数を指定することによって、これらのディレクトリ以外に共有ファイルを置くこともできます。


第5章 Armadilloの基本操作	PDF version	第7章開発環境の構築と基本操作