次のページへSubversionのコンパイル&インストール下準備ができたところで、Subversionのインストールに取り掛かりましょう。Subversionのアーカイブ入手と展開まず、Subversionのtarボールを入手、展開します。Sharingメニューの1つ(http://subversion.tigris.org/servlets/ProjectDocumentList?folderID=74)から入手可能です。今回は、原稿執筆時点での最新版であるsubversion-r2291.tar.gzを使用しました(注)。注:Subversionで管理されているリポジトリからスナップショットを取得する手もありますが、ここではtarボールで配布されているものを紹介します。-configureとmaketarボールを展開したら、生成されたディレクトリに移動してconfigureとmakeを実行します。2.0のビルドツリー配下にあるものを指定します。--with-berkeley-dbは、DBライブラリをインストールしたディレクトリを指定します。DBの検出がうまくいかないなどでconfigureが失敗することがありますが、これについてはトラブルシューティングとして後述します。Subversionのインストールmakeが終わったら、rootになってインストールを行います。installこの時点で、httpd.confにSubversion用のモジュールを組み込む設定が追加されます。2行目のrmコマンドは、「古いライブラリを明示的に消去するように」というドキュメントの記述に従っています(注)。注:Subversionを初めてインストールする場合などは必要ありません。筆者は、何十回となくインストールを繰り返したので、この作業を実施するのが染み付いています。mod_encodingのコンパイルで発生したようなlibtool関係の問題については、Subversionが自前でlibtoolを生成するため、発生しません。次世代プロトコルWebDAVの可能性で説明した方法と何ら変わるところはありません。以下の(1)と(2)は順序を逆にして実行しても問題ありません。リポジトリのエントリ追加httpd.confの中に、以下のようにしてリポジトリのLocationとSubversionの使用、そして実際のPATHを指定します。リポジトリの作成SVNPathで指定した/home/svn/reposの配下にSVNリポジトリを作成します。/home/svnをあらかじめ作成しておく必要があります。リポジトリの作成には、svnadminコマンドを使用します。/home/svn最後にnobodyにchownしているのは、httpdの権限で実際にリポジトリを読み書きできるようにするためです。ここまでで作成されたリポジトリの様子を以下に示します。db.lockhttpdの起動と試験ここまでの設定で、Subversionが使用できるようになるはずです。2.0を起動してみましょう。startちゃんと動いているかどうかのチェックは、OPTIONSメソッドを「(1)リポジトリのエントリ追加」で指定したLocationに対して発行することで行えます。以下にチェックの例を示します。host.おおよそこんな感じのメッセージが出てくれば、インストールは成功しています。許可されているメソッドについては、一部出力されないものもあります。Subversionのインストールトラブルシューティング今回の記事を書くに当たっての検証では、いくつか大きなトラブルが出ています。ドキュメントを読んだだけではまったく分からないものもいくつかあります。ここでは、そういったトラブルとその対策についていくつか述べてみます。Runtime)ライブラリを利用します。ところが、正式リリースされた後もAPRのAPIがFIXされず、コンパイルできないなどということが発生することがあります。2.0で利用されているものに差し替えるのが一番の早道です。2.0のどのバージョンを使ってビルド&機能チェックしているのかが不明なため、上記のような事象が発生した場合はAPRライブラリのAPIなどの不整合を疑ってみてください。インストール時に、--with-aprおよび--with-apr-utilを明示的に指定しているのは、このトラブルを避けるためです。すると、tarボールに同梱されているAPRおよびARP-UTILは使われません。コンパイル、インストールはできたが、OPTIONSメソッドによるチェックが成功しない一番ありがちなのは、こちらの事象でしょう。以下に、実際に発生した例を示しますが、ここでは「データベースのバージョンが不正である」というエラーが出ています。host.libsvn_fs-1.soというライブラリにおいて、DBライブラリのバージョンチェックを実施しているのですが、このトラブルはそのバージョンチェックで返却されたバージョン値が「期待されているものよりも古い」ことに起因しています。2.0で有効なDBライブラリのバージョンが古いことにほかなりません。このような事象が発生する原因は、以下の2つが考えられます。httpdが参照しているDBライブラリが古いlibsvn_*で参照しているDBライブラリがまちまちそれぞれの場合における解決方法の例を以下で説明します。httpdが参照しているDBライブラリが古いこちらの問題が発現していると、libsvnにおいていくら新しいDBライブラリを参照するようにしていても、決してSubversionが動作することはありません。問題が発生している場合に、httpdについてlddを実行した結果を示します。(0x40000000)解決法としては、2つあります。2.0をインストールし直す本格的な対処です。2.0をインストールして「Subversionが動かない」という方は、まずインストールされたhttpd実行ファイルについてlddコマンドを実行し、その結果を確認してみてください。(強引に)新しいDBライブラリを参照するようにするhttpdのバイナリ中で、db-3.3.so(環境によって異なる)と記述されている部分をdb-4.0.soと修正し、新しいDBライブラリを参照するようにします。2.0を再インストールしたくない場合に有効です。この方法で修正したバイナリを使用して不具合が起きる可能性は否定できないため、あくまで急場しのぎと考えてください。画面1に、実際にEmacsを用いた編集の様子を(libdb-3.3.soという文字列を探し出したところ)を、画面2に保存の様子を示します。修正したファイルを保存その結果更新されたバイナリファイルに対してlddコマンドを実行した結果を以下に示します。httpdとしてhttpdに実行権を付加した後にlddを再実行してみてください。libsvn_*で参照しているDBライブラリがまちまちhttpdがDBライブラリを参照していない場合は、こちらの原因でトラブルが発生することがあります。4.0を参照しているものが混在したり、古いライブラリを参照したりと、動作不安定の原因にしかなりません。libsvn_*の結果を示しますが、libdb-4.0を参照したりlibdb-3.3を参照したりとまちまちなのが分かります。解決方法として理想的なのは、どちらの場合においても新しいDBライブラリを参照するようにすることです。4.0.14のアーカイブを展開し、作成されたディレクトリをdbとリネームするlibdb-3.3.soを参照しているダイナミックリンクライブラリの内容を修正し、db-4.0.soを参照できるようにするいずれの場合も、Subversionのconfigure時に以下のような形になることがあります。-ldb-4.0などとして、必ず/usr/local/BerkeleyDB.4.0/lib配下のlibdb-4.0.soを参照するように記述するという手もあります。メールマガジンをご購読ください。申し込みページへITmediaはアイティメディア株式会社の登録商標です。