開発環境の構築
例えば、ソースファイルで配布されているソフトをコンパイルして使いたい場合、知っておいた方が良い事が幾つかある。インストール先のディレクトリや設定に関する事だ。
確かにコンパイルしたいだけなら IDE やコンパイルツールをインストールすれば済むのだが、それでは忘れた頃に問題が発生する事も珍しくない。
※ このページで使用している yum 関連コマンドは、全て管理者権限で行う必要があります。
※ Fedora22 からは DNF を用いてインストールを行います。詳しくはコチラをご覧下さい。
システムとディレクトリの意味
ディレクトリにはそれぞれ意味がある。そこで、インストールなどに関連する基本的なディレクトリについて説明しよう。
コンパイルしたファイルのインストール先
ソースからコンパイルしたファイルなどは、通常、「/usr/local」か「/opt」にインストールするべきである。Fedora を含む多くの Linux はパッケージャーによって管理されており、「/usr/bin」や「/usr/lib」、「/usr/lib64」などにインストールしてしまうと、実行時エラーやパッケージャーが依存エラーを起こすことも珍しくない。
パッケージャーはコマンドやアプリ、ライブラリ、フォント、アイコン、資料ドキュメントなども管理しているので注意が必要だ。
例えば架空ライブラリ「libA.so」が「/usr/lib64」 に、「libA.so」、「libA.so.1」、「libA.so.1.2.8」として存在とする。
そして、実体は「libA.so.1.2.8」、そのシンボリックリンクが「libA.so」、「libA.so.1」であったとする。
あるプログラム「A」が「libA.so」を動的リンクしているとする。
ここで新たに ver 1.5 のライブラリをソースからコンパイルし、インストールしたする。
だたし、ver 1.5 では非推奨であった func_1 が削除され、代わりに func_2 が含まれているものとする。
この時、プログラム「A」を実行しようとすると、当然、失敗する。
これは仮定の話だが、実際に非推奨の関数などが削除されるのは珍しい事ではない。「/usr/lib64」を覗いてみれば分かるかと思うが、同一名のライブラリが複数入っている事が確認出来るだろう。しかし、パッケージャーはバージョンも管理しているので、通常コレが問題になる事は少ない。
こういった問題はライブラリに限った話ではないので、「/usr/bin」や「/usr/lib64」にコンパイルしてインストールする事は推奨されていない。
その為、ライブラリなどもパッケージャーからインストールするのである。
これを回避する目的で利用されるのが「/usr/local」や「/opt」になるワケだ。
コンパイル環境の構築
一口にコンパイルと言っても、様々なツールが必要だ。そこで、少し横着をしよう。
yum にはグループインストールと言う方法があるのでソレを利用する。ここでは Yum Extender を利用する。
※ Ubuntu では、SDKパッケージを利用。ただし、PPA リポジトリが充実しているので、コンパイルは殆ど必要ないハズ。
※ Fedora22 からは DNF を用いてインストールを行います。詳しくはコチラをご覧下さい。
Yum Extender を起動した後、『グループ』を選択してから『開発環境』の『C 開発ツールとライブラリー』を選択し、『適用』をクリック。
※ コマンドで行うなら「yum groupinstall ‘C 開発ツールとライブラリー’」
次に、Anjuta（パッケージ名は anjuta）もインストールしておこう。Anjuta は、「configure」や「autogen」のプロジェクトを作成・管理する IDE（総合開発環境）だ。
※ コマンドで行うなら「yum install anjuta」
コンパイル
例えば、コンパイルに libtiff パッケージが必要な場合、同時に libtiff-devel パッケージが必要になる。この場合、 libtiff はライブラリ本体、libtiff-devel パッケージには、C/C++ のヘッダーファイルなどが含まれる。通常のコンパイルには、この２つはペアで必要になるので、「-devel」パッケージも忘れない様にインストールしておこう。ただし、ライブラリであっても、 babl や lcms2 などのように、lib から始まらないパッケージもあるので、注意が必要だ。
また、GIMP などのアプリケーションでは、必要になるライブラリなどが膨大になる。そこで yum には、そう言った場合の為に、「yum-builddep」コマンドが用意されている。
「yum-builddep パッケージ名（ gimp などを指定）」（dnf を使用している場合は、「dnf builddep パッケージ名」を使用する。）
このコマンドを利用することで、手間を大幅に省く事ができる。
ここでは、システムの gimp が 2.8 で、gimp 2.9 をインストールする例で見てみよう。
なお、ここでのインストール先は /usr/local/ とする。
$ # ここでは「su -c」を利用しているが、勿論、「sudo」でも構わない。
$ # DNF を利用している場合は、「sudo dnf builddep」を使用する。
$ su -c “yum-builddep gimp”
$
$ # ホームディレクトリ直下に「build」ディレクトリを作成し中に入る。
$ mkdir ~/build
$ cd ~/build
$
$ # 念の為に、初期化。
$ git init
$
$ # ここで、GIMP 2.9 には最新版の BABL と GEGL が必要なので入手する。
$
$ # BABL の最新版を入手。
$ git clone git://git.gnome.org/babl
$
$ # GEGL の最新版を入手。
$ git clone git://git.gnome.org/gegl
$
$ # GIMP の最新版を入手。
$ git clone git://git.gnome.org/gimp
$
$ # 環境変数を設定
$ # インストール先は /usr/local
$ # ライブラリなどは、/usr/local を優先する用に、変更
$ export PREFIX=”/usr/local”
$ export PATH=”${PREFIX}/bin:${PATH}”
$ export PKG_CONFIG_PATH=”${PREFIX}/lib/pkgconfig:${PKG_CONFIG_PATH}”
$ export LD_LIBRARY_PATH=”${PREFIX}/lib:${LD_LIBRARY_PATH}”
$ export ACLOCAL_FLAGS=”-I ${PREFIX}/share/aclocal ${ACLOCAL_FLAGS}”
$
$ # 先ずはライブラリの BABL からコンパイル＆インストール
$
$ cd babl
$ # autogen.sh か configure のどちらか一方を実行。どちらも無い場合は、この工程は省略
$ ./autogen.sh –prefix=”${PREFIX}”
$ make
$ su -c “make install”
$ cd ../
$
$ # ライブラリの GEGL をコンパイル＆インストール
$
$ cd gegl
$ # autogen.sh か configure のどちらか一方を実行。どちらも無い場合は、この工程は省略
$ ./autogen.sh –prefix=”${PREFIX}”
$ make
$ su -c “make install”
$ cd ../
$
$ # GIMP のコンパイル＆インストール
$ # 当然だが、ライブラリの使用者でもある GIMP を必ず最後に行う。
$
$ cd gimp
$ # autogen.sh か configure のどちらか一方を実行。どちらも無い場合は、この工程は省略
$ ./autogen.sh –prefix=”${PREFIX}”
$ make
$ su -c “make install”
$ cd ../
$
$ # これで /usr/local にインストールされた。
アプリケーションアイコンの設定
1024×1024 16×16 22×22 256×256 32×32 36×36 48×48 512×512 64×64 96×96 index.theme
128×128 192×192 24×24 26×26 34×34 40×40 50×50 64×50 72×72 icon-theme.cache scalable
それぞれのディレクトリの下の「apps」ディレクトリ配下に PNG ファイルがサイズ毎に格納されているのが確認出来る。 ※ 「scalable」（可変サイズ）に格納されるのは、例外的に SVG ファイル。
別に１つでも良いので、サイズにあった画像を用意するしてインストールすればOKだ。複数用意する場合は、全て同じファイル名にする必要がある。
拡張子「.desktop」で、「/usr/share/applications/」または「/usr/local/share/applications/」に格納。フォーマットVersion=バージョン（同一アプリケーションが複数インストールされた場合は、大きい数字のモノが起動される）Name=アプリケーション名（英語）必須Name[ja]=アプリケーション名（日本語）GenericName＝エディタ・WEBブラウザなどの一般名（英語）GenericName[ja]＝エディタ・WEBブラウザなどの一般名（日本語）NoDisplay=true/false インターフェースを持たないツールなどは true 通常は falseComment=アプリケーションの説明など（英語）Comment[ja]=アプリケーションの説明など（日本語）Type=Application/Link/Directory 必須（通常は Application を使用）Icon=アイコンファイル（拡張子は不要／相対・絶対パスで画像ファイルの指定も可能：この場合は拡張子も含む）Exec=アプリケーション本体Path=アプリケーションを実行するパスTerminal=true/false 端末で起動する必要がある場合は true 通常は falseMimeType=アプリケーションが開くことが出来るファイルタイプを MIME タイプで指定。セミコロン（;）で分割し、複数指定も可能Categories=カテゴリーを指定。セミコロン（;）で分割し、複数指定も可能（英語）Keywords=キーワードを指定。セミコロン（;）で分割し、複数指定も可能（英語）Keywords[ja]=キーワードを指定。セミコロン（;）で分割し、複数指定も可能（日本語）
アプリケーションの作成
実行ファイルの作成は、Shell や Python スクリプトなどでも作成が可能だ。事実、幾つかのコマンドやアプリケーションはスクリプトで作成されている。しかも、拡張子を付加しないのが一般的だ。
それでは何故、バイナリーやスクリプトの識別が可能なのだろうか？
答えは簡単である。先ずは実行権の有無をチェックし、実行可能ファイルである場合のみ起動シーケンスに入り、実行するためにファイルをロード（読み込み）する。そして、ヘッダ情報でファイルのタイプを識別し、適切な実行を行う。
スクリプトファイルの場合、ヘッダー情報には、起動すべきプログラムが指定される。
実際に shell スクリプトで実例を見てみよう。なお、スクリプトファイル名は「SampleScript」とします。
echo “hellow world”
そして、このスクリプトへ実行権を付与しておきます。「chmod +x SampleScript」
実行可能なスクリプトは通常、「#!(実行プログラムの絶対パス) [引数やオプション]」で始まります。そして、ファイルの内容は実行プログラムの標準入力へとパイプされます。
ここで少し、実験をしてみましょう。
abedefg
hijklmn
このようなスクリプトファイルを用意し、実行権を付与して実行してみましょう。
$ ./SampleScript2
#!/bin/cat
abedefg
hijklmn
$
結果は、ファイルの内容が、そのまま表示される事が確認出来るかと思います。
では、バイナリーの実行ファイルはどうやって識別しているのでしょうか？
magic ファイルを用いた判定を行っています。判定結果を得る場合は「file」コマンドが利用できます。
※ 詳しい情報は、「man file」や「man magic」で確認して下さい。
実は、バイナリーの実行ファイルも形式は様々ですが、同様にヘッダー情報が含まれており、それを元に実行しています。
先のスクリプトファイルに対して「file」コマンドを実行してみれば分かるかと思いますが、ヘッダー情報がファイルを識別する方法になっているのが、理解できるかと思います。
また、例外的にスクリプトファイルは「#!/bin/env python」の様に、「#!/bin/env」や「#!/usr/bin/env」から始まる事があります。コレは、環境変数を読み込んで実行する事を意味し、shell 以外のスクリプトにしばしば利用されます。例えば「#!/bin/env python」であれば、環境変数 $PATH を参照して起動され、その他の基本的な環境変数もセットされます。詳しくは「man env」をご覧ください。
