heads-up
zlib 1.2.4 and versioned symbol
current - Revision 205471 のコミットで9-CURRENTのzlibが1.2.4にアップグレードされました。このアップグレードでシンボルバージョニングの機能が実装されています。以後、zlibはメジャーバージョンがアップデートされた場合でも後方互換性が確保されるため、同ライブラリに依存するアプリケーションやライブラリをリビルドする必要がなくなります。
ただし、今回のアップデートまでは同ライブラリを利用するアプリケーションやライブラリのリビルドが必要です。次にいくつかのアップデート方法と問題の回避方法を紹介します。
対応1 リビルド
zlibに依存しているアプリケーションやライブラリを再構築します。たとえば、特定のライブラリに依存しているサードパーティアプリケーションを調査するために次のようなスクリプトを、たとえばldck(1)といった名前で用意しておき、次のように依存しているアプリケーションを調べます。
リスト 特定のライブラリに依存しているアプリやライブラリを探すスクリプトldck(1)
#!/bin/sh
case ${#} in
0)
echo "ldck library.so.#"
exit 1
;;
esac
obsoletelibrary=${1}
find -f /usr/local/lib/ -f /usr/local/bin/ |
while read target
do
check=$(ldd ${target} 2> /dev/null | grep ${obsoletelibrary})
if [ -n "${check}" ]
then
port=$(grep -E "^${target#/usr/local/}\$" /var/db/pkg/*/+CONTENTS | head -1)
port=${port#/var/db/pkg/}
port=${port%%/+CONTENTS*}
echo "$port"
fi
done |
sort | uniq
ldck(1)を使ってlibz.so.5に依存しているアプリやライブラリをチェック
# ldck libz.so.5
GeoIP-1.4.6
GraphicsMagick-1.1.15_2,1
ImageMagick-6.5.8.10_1
OpenEXR-1.6.1_2
...
xv-3.10a_13
xvid4conf-1.12_4
yelp-2.28.1_2
zenity-2.28.0_1
#
portupgrade(1)やportmaster(1)を使って対象をアップグレードします。しかし、この方法は次の理由から今回はあまりお勧めできません。
zlibに依存しているアプリケーションやライブラリはかなり多くあります。ビルドに必要になる基盤ツールやライブラリがzlibを使っているものが多く、問題ないようにアップグレードを実施するのは難しい状況にあります。
2010年4月10日前後あたりまで、Ports Collectionは影響範囲の広いコミットが連続して実施される計画になっています。その間混乱も予想されるため、リビルドとアップデートを繰り返すと不具合が発生した場合の問題の特定が困難になる可能性があります。
アップデートされたzlibにはいくらか改善すべきポイントが見られます(回避方法は後述)。アップデートで対処した場合、zlibに問題があるのかアップデート手順に問題があったのかわかりにくくなる可能性があります。
zlibに依存しているアプリやライブラリを個別にリビルドする方法は、ウィンドウプラットフォームを利用しておらずインストールしてあるアプリケーションの数が少ない場合などに有効な方法といえます。
対応2 フル再インストール
影響範囲が大きいことから、一旦すべて削除してからすべてクリーンインストールする方法がお薦めです。全削除には「pkg_delete -af」などが使えます。古いファイルによる影響を避けたい場合は全削除後に/usr/local/以下のファイルをすべて削除するなどしておくと便利です。なお、必要なファイルのバックアップは忘れないように実施しておいてください。
2010年4月10日前後あたりまで、Ports Collectionは影響範囲の広いコミットが連続して実施される計画になっています。その間混乱も予想されるため、フル再インストールには2010年3月20日あたりのツリーを使うか、2010年4月10日以降の落ち着いてきたタイミングでの実施が望まれます。
アップデートされたzlibにはいくらか改善すべきポイントが見られます。フル再インストールする場合、後述するトラブルシューティングも参考にしてください。
対応3 バイナリレベルで対処
アプリケーションの再インストールを実施せずに、バイナリレベルで互換性を保つという方法もあります。おもに次の2つの対処方法があります。
libz.so.5など古いバージョンのバイナリを削除せずに保持しておく。
libmap.conf(5)を使ってlibz.so.5への参照を新しいlibz.soへ向ける。
libmap.conf(5) (/etc/libmap.conf)は例えば次のように記載します。
リスト /etc/libmap.conf - libz.so.5をlibz.soへ向ける設定
libz.so.5 libz.so
すでにビルドされたバイナリやライブラリには効果がありますが、これからビルドする場合には効果がありません。アップデートされたzlibにはいくらか改善すべきポイントが見られますので、これからビルドするものに関しては後述するトラブルシューティングも参考にしてください。
トラブルシューティング1 新しいzlibでビルドできない
アップデートされたzlib、特にzconf.hの設定にはいくらか不備がみられます。これが原因で9-CURRENTではリビルドに失敗するアプリケーションやライブラリがいくつかあります。こうした場合、たとえば/usr/include/zconf.hに次のような変更を加えることでビルドできるようになります。ほかのエラーが出力される場合、同様の方法で対処できることがあります。
リスト /usr/include/zconf.hへの修正例
--- /usr/include/zconf.h.orig 2010-03-28 19:06:20.000000000 +0900
+++ /usr/include/zconf.h 2010-03-28 19:08:26.000000000 +0900
@@ -393,6 +393,7 @@
#ifndef _FILE_OFFSET_BITS
#define _FILE_OFFSET_BITS 64
#endif
+typedef off_t off64_t;
#ifndef z_off_t
# define z_off_t long
いずれ9-CURRENTに何らかの対処が実施されると見られるため、この対処は不要になっている可能性もあります。あくまでも場当たり的な対処で、最終的には9-CURRENT側での正式な対処が期待されます。