pkg-configは、ライブラリの利用に必要となる情報を提供するツールです。 環境変数 PKG_CONFIG_PATH に定義されているパスに置かれている *.pc ファイルから情報を取得し、それを返します。
環境変数 PKG_CONFIG_PATH はすでに定義済みです。 すでに実施した事前準備 > MinGWのセットアップ - 4. .profileファイルの作成 -で、.profileファイル内に記述しました。 その内容は以下の通りです。
export PKG_CONFIG_PATH=/working/gimp/lib/pkgconfig:/working/tools/lib/pkgconfig
まず、ソースファイルを展開します。 MinGW Shell上で以下を実行します。
cd /working/sourcestar xvf /working/sources/pkg-config-0.27.1.tar.gz cd pkg-config-0.27.1
続いて、configureを実行します。 MinGW Shell上で以下を実行します。
CPPFLAGS="-march=pentium -mtune=pentium" \./configure \ --prefix=/working/tools \ --with-internal-glib > ../configurelog.pkgconfig 2>&1
configureが終了したら、ログファイルに出力された内容を参照し、正常に終了したことを確認します。
cat ../configurelog.pkgconfig
以下は正常に終了した場合の例です。
...(省略)... configure: creating ./config.status config.status: creating Makefile config.status: creating glib/Makefile config.status: creating glib/libcharset/Makefile config.status: creating glib/gnulib/Makefile config.status: creating m4macros/Makefile config.status: creating config.h config.status: executing depfiles commands config.status: executing libtool commands config.status: executing glib/glibconfig.h commands
以下のように、"error" と表示されていれば問題が発生したことを意味しています。
...(省略)... checking for an ANSI C-conforming const... yes checking for size_t... yes checking whether struct tm is in sys/time.h or time.h... time.h checking for C/C++ restrict keyword... __restrict checking for working strtod... yes checking for memset... yes checking for pow... yes checking for zlibVersion in -lz... no checking for z_zlibVersion in -lz... no configure: error: zlib not installed
続いて、ビルドを実行します。 MinGW Shell上で以下を実行します。
make
makeが終了したら、画面に出力された内容を参照し、正常に終了したことを確認します。 以下は正常に終了した場合の例です。
...(省略)... pkg.c:884:21: warning: unknown escape sequence: '\/' [enabled by default] CC parse.o CC main.o CCLD pkg-config.exe make[2]: Leaving directory `/working/sources/pkg-config-0.27.1' Making all in check make[2]: Entering directory `/working/sources/pkg-config-0.27.1/check' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/working/sources/pkg-config-0.27.1/check' make[1]: Leaving directory `/working/sources/pkg-config-0.27.1'
続いて、インストールを行います。 MinGW Shell上で以下を実行します。
make install
インストールが終了したら、画面に出力された内容を参照し、正常に終了したことを確認します。 以下は正常に終了した場合の例です。
...(省略)... /bin/install -c -m 644 pkg-config.1 '/working/tools/share/man/man1' make[2]: Leaving directory `/working/sources/pkg-config-0.27.1' make[1]: Leaving directory `/working/sources/pkg-config-0.27.1' Making install in check make[1]: Entering directory `/working/sources/pkg-config-0.27.1/check' make[2]: Entering directory `/working/sources/pkg-config-0.27.1/check' make[2]: Nothing to be done for `install-exec-am'. make[2]: Nothing to be done for `install-data-am'. make[2]: Leaving directory `/working/sources/pkg-config-0.27.1/check' make[1]: Leaving directory `/working/sources/pkg-config-0.27.1/check'
ここでは、configureの実行時に、
CPPFLAGS="-march=pentium -mtune=pentium" \ ./configure \ --prefix=/working/tools \ --with-internal-glib > ../configurelog.pkgconfig 2>&1
のように、実行するシェルのパス(./configure)の前に変数 CPPFLAGS を付加しています。 上記のコマンドは複数行に分けているため見づらいですが、1行で記述すると以下になります。
CPPFLAGS="-march=pentium -mtune=pentium" ./configure --prefix=/working/tools --with-internal-glib > ../configurelog.pkgconfig 2>&1
上記のように ./configure の前に変数 CPPFLAGS が定義されています。 一般的に、シェル内の変数といえば、
NAME=value
と記述するシェル変数(子シェルには渡されない)や、
NAME=value export NAME
または、
export NAME=value
と記述する環境変数(子シェルにも渡される)が知られています。
実は、上記のシェル変数と環境変数以外にも、子シェルにだけ渡される一時的な変数があります。 一時的な変数は、
NAME=value run.sh
と記述します。 この場合には run.sh に変数 NAME が渡されますが、呼び出し元のシェル(コマンドを打ち込んだシェル)には変数 NAME は定義されません。
つまり、run.sh が実行されている間だけ、run.sh 内に存在する変数というわけです。
ここでは、configureの実行結果を、
CPPFLAGS="-march=pentium -mtune=pentium" \ ./configure \ --prefix=/working/tools \ --with-internal-glib > ../configurelog.pkgconfig 2>&1
のように、親ディレクトリの configurelog.pkgconfig ファイルにリダイレクトしていますが、リダイレクトの後ろに、
2>&1
と記述しています。 この記述は、標準エラー出力への出力内容を標準出力へ流し込むためのものです。
例えば、
run.sh > run.log
として実行すると、標準出力への出力内容は run.log ファイルへ出力されますが、標準エラー出力への出力内容は画面に表示されます。
そこで、
run.sh > run.log 2>&1
として実行することで、標準エラー出力への出力内容を標準出力へ流し込み、さらに標準出力への出力内容を run.log ファイルへ出力させることができます。 つまり、画面への出力内容の全てを run.log ファイルへ出力することができます。
リダイレクト関連の記述は順序が大切です。 例えば、
run.sh 2>&1 > run.log
として実行してしまうと、画面への出力内容の全てを run.log ファイルへ出力することはできません。
リダイレクトの記述はコマンドラインの後ろから前に向かって解釈されます。 つまり、上記の例だと、標準出力への出力内容が run.log ファイルへ出力された後に、標準エラー出力への出力内容が標準出力へ出力されます。 ということは、
run.sh > run.log
と同じ結果にしかならないということです。
なお、
run.sh 2> run.log > run.log
や、
run.sh 2> run.log > 1> run.log
として実行してしまうと、やはり、画面への出力内容の全てを run.log ファイルへ出力することはできません。
なぜなら、上記の例だと、標準出力への出力内容が run.log ファイルへ出力された後に、標準エラー出力への出力内容が run.log ファイルへ出力されてしまうためです。 つまり、標準エラー出力への出力内容で上書きされてしまうのです。
もっと簡単に、
run.sh >& run.log
と記述することで、
run.sh > run.log 2>&1
と同じ結果を得られます。
なお、この記述は、sh、bash、ksh、zsh、csh、tcshで使えるようです。