configureでソフトウェア固有の設定を変更してみる：仕事で使える魔法のLAMP（13）

ソフトウェア固有の設定

　前回はインストールディレクトリやコンパイラの種類をconfigureスクリプトで指定する方法を解説しました。インストールやコンパイルはどのソフトウェアでも必要な作業ですから、configureが付属しているソフトウェアでは共通の方法で設定できるようになっています。今回はソフトウェアごとに異なる固有の設定について説明します。

　configureで指定できるソフトウェア固有の設定は、インストールディレクトリと同様に引数で指定します。「--help=short」という引数でconfigureを実行すると、その一覧を表示できます（図1）。

Configuration of GNU Hello 2.7:
 
Optional Features:
  --disable-option-checking  ignore unrecognized --enable/--with options
  --disable-FEATURE       do not include FEATURE (same as --enable-FEATURE=no)
  --enable-FEATURE[=ARG]  include FEATURE [ARG=yes]
  --disable-dependency-tracking  speeds up one-time build
  --enable-dependency-tracking   do not reject slow dependency extractors
  --disable-nls           do not use Native Language Support
  --disable-rpath         do not hardcode runtime library paths
 
Optional Packages:
  --with-PACKAGE[=ARG]    use PACKAGE [ARG=yes]
  --without-PACKAGE       do not use PACKAGE (same as --with-PACKAGE=no)
  --with-gnu-ld           assume the C compiler uses GNU ld default=no
  --with-libiconv-prefix[=DIR]  search for libiconv in DIR/include and DIR/lib
  --without-libiconv-prefix     don't search for libiconv in includedir and libdir
  --with-libintl-prefix[=DIR]  search for libintl in DIR/include and DIR/lib
  --without-libintl-prefix     don't search for libintl in includedir and libdir
（以下略）

　2つのカテゴリがあることがすぐに見て取れます。「--enable-foo」のようにenableで始まるものと、「--with-foo」のようにwithで始まるものです。

　前者は、主にそのソフトウェアの機能や動作方法などを設定するためのものです。デフォルトで無効になっているものを有効にするにはenable。有効になっているものを無効にするにはdisableと指示します。あるいは「--enable-foo=no」というような指定も可能です。

　ヘルプ表示を見ると、デフォルトから設定を変えるための指示方法を確認できます。デフォルトで有効であればdisableがヘルプに表示されるということです。ただし、configureスクリプトの実行時にどちらかが決まるような場合は、enableとdisableの両方がヘルプに記してあることもあります。

　withは主に外部のソフトウェアやライブラリを組み込むように指示するときに使います。組み込みたくない場合はwithoutを指定しますが、動作に欠かせない外部のライブラリをwithoutに指定することはできません。必ず必要なソフトウェアがOS内に見つからない場合、configureスクリプトの実行時にエラーになります。withによる指定には例外も多く、外部のソフトウェアとは関係のない引数もあります。

enableとdisableで機能を制御

　前回に引き続き、GNU Helloを題材に実践してみましょう。図1にあるenable/disable指定をよく読むと、実際にソフトウェアの固有の設定と言えるのは「--disable-nls」だけです。NLSとは、Native Language Supportの略で、いわゆる国際化機能です。前回、helloコマンドは日本語などでも表示できることを確認しましたが、その機能です。

　次のようにconfigureを実行します。「--disable-nls」を指定しているので、NLS機能が無効になるはずです。インストール先は前回とはちょっと変えてあります。

$ ./configure --prefix=/opt/hello-2.7_1 --disable-nls

　configureの出力の最後の方に、次のような行が出力されます。これでNLS機能が無効になったことが分かります。

checking whether to use NLS... no

　いつも通りにビルドします。

$ make
$ sudo make install

　インストールが無事完了したら、実行してみましょう。

$ /opt/hello-2.7_1/bin/hello
Hello, world!
$ env LANG=ja_JP.UTF-8 /opt/hello-2.7_1/bin/hello
Hello, world!

　環境変数LANGで日本語を指定しても、日本語表示をしなくなりました。ビルド時の設定を変えることで、実行形式ファイルの機能が変化したことが分かります。さらに、インストール内容も変わっています。

$ ls -p /opt/hello-2.7/share
info/  locale/  man/
 
$ ls -p /opt/hello-2.7_1/share
info/  man/

　前者が、前回インストールしたものです。今回インストールした方には、翻訳データを格納してあるlocaleディレクトリがありません。configureスクリプトは、引数の指定からビルド方法を変えるだけでなく、同時にインストール実行部分も最適に変えているのです。

インクルードファイルの場所を指定

　withで外部のソフトウェアやライブラリを指定するときは、多くの場合、インクルードファイルがあるディレクトリを指定します。「--with-foo=ディレクトリ」のような引数となるわけです。ディレクトリを省略すると、OS標準のディレクトリを対象に目的のファイルを検索します。

　インクルードファイルは第7回で解説したライブラリとペアで存在しているものです。C言語やC＋＋言語では、コンパイルの際にライブラリにどういったものが含まれているかという情報が必要になります。

　その情報を記述したファイルを、ライブラリを使うプログラムのソースコードに読み込む（インクルードする）ことから、インクルードファイルと呼ぶのです。また、プログラムの冒頭部分で読み込むため、ヘッダファイルともいいます。拡張子は.hですが、これはヘッダが由来です。

　それでは図1のGNU Helloのwith指定を見てみましょう。「libiconv」と「libintl」の指定ができるようになっています。これらは国際化や文字コード変換のためのライブラリです。つまり、「--enable-nls」設定のために必要なライブラリということになります。しかし、実はLinux上では、これらの指定は不要です。実際にwithoutとしてもビルドが成功しますし、国際化機能も有効です。

　Linuxでは標準ライブラリ（libc）としてGNU C Library（glibc）を使いますが、glibc内部にはすでに国際化機能が存在しているのです。configureスクリプトの出力の最後の方に、次のような行があります。

checking whether to use NLS... yes
checking where the gettext function comes from... libc

　gettextは国際化のための関数です。libc内にあるものを使う、という表示になっています。

　withの実際の使用例は次回以降で、取り上げることにします。

ソースコードパッケージの確認は欠かさずに

　ここからは少々話が変わります。つい先日、vsftpdというFTPサーバソフトウェアのソースコードにバックドアが仕掛けられ、数日間にわたって配布されていたという事件がありました。バックドアというのは、コンピュータへの侵入を許すような裏口のことです。どのような経緯でソースコード配布パッケージが置き換えられたのかは不明ですが、ミラーサイトではなく配布元のサイトで置き換えられたとのことです。

　第10回で、ソースコード配布パッケージを入手したら真正なものであることをちゃんと確認しましょうということを書きました。この事件でも電子署名を確認していれば、偽物だということは判明していたそうです。

　執筆後まもなくこういう事件が起こるとは想像もしませんでしたが、電子署名による確認が欠かせないものだということを実感していただけるかと思います。

　次回は、Apache HTTP Serverのビルドに取りかかります。