ruby-1.9.3-p392とrails3.2.13 を CentOS 6.4 にインストールするまで (2)

Railsインストールを再開
前回の記事で無事、Rubyをインストールできた（と思っていた）筆者は、すかさず立て続けにrails のインストールを開始した。

> gem install rails

しかし結果は

no such file to load -- zlib (LoadError)

訳の分からんエラーが出て全く先に進まなくなってしまったではないか。なんじゃこれは？
ひとしきり焦った挙句、どうやらファイル圧縮/解凍ツールのライブラリであるzlibが呼び出せないらしいということまでは理解できた。
とりあえずyum で片っ端からzlib 関連のライブラリのインストールを試してみる。こんな当てずっぽうでこの手の問題が解決したことがないが、とにかくやってみた。

> yum list | grep zlib
zlib.x86_64                            1.2.3-29.el6   @anaconda-CentOS-201303020151.x86_64/6.4
zlib-devel.x86_64                    1.2.3-29.el6   base
zlib-static.x86_64                   1.2.3-29.el6   base
...
...
> yum install zlib.x86_64  #既にインストール済みなので無駄    
> yum install zlib-devel.x86_64
> yum install zlib-static.x86_64

やるだけやってみたが、結果は何も変わらない。経験則が正しかったと言う以外には特に得るものがなかった。
そこで一旦、考えを整理してみた。
zlibというのは、rubyの標準添付ライブラリだが、元々はrubyとは関係のないC言語で作成された外部ライブラリである。それをrubyから使えるのは、恐らくはスタティックリンクかダイナミックリンクで結合しているに違いない。従って、
no such file to load -- zlib (LoadError)
というエラーはライブラリをメモリ上にロードできなかったということを意味する。要するに、ライブラリ参照エラーだ。zlibライブラリ本体がないか、それともライブラリの存在をconfigureスクリプトが認識してないか、ということだ。もしこの推測が正しいなら他の外部ライブラリ参照系のruby側ライブラリもいくつかは構築に失敗しているはずだ。
前の記事ではlibyaml をインストールした後、そのライブラリをconfigureスクリプトに認識させるために、敢えて--with-opt-dir=というオプションをつけて、ライブラリのパスを指定していた。それならzlib本体の場所もこれと同じ方法で教えたらどうだろう？　

./configure --with-opt-dir=/usr/local --with-opt-dir=/usr/lib64 --enable-shared --enable-option-checking

すると上記の推測は見事に(?)当たり、以下のコマンドがすんなり実行されるようになった。

# gem list --remote rails
*** REMOTE GEMS ***
rails (3.2.13)
rails-3-settings (0.1.1)
rails-action-args (0.1.1)
....
....

どうやら、/usr/lib64 というディレクトリ構成をRubyのインストーラ作者がフォローしきれなかったか、CentOSが独自に作っているパスのために認識できなかったんだろう。

さてこれでようやく後はRails をインストールするだけというところまできた。だが、筆者はここまでの作業を通じてこの手のインストールトラブルの類が他にもあるのではないかという気がしていた。似たような問題で一見解決方法が分からなくなるようなトラブルに関しては事前に避けておきたいものだ。
調べてみると、open-ssl （の開発環境）の存在が webrickの動作に依存関係を持っているという記事を見つけた。[Rails]railsで、opensslのモジュールが無いと怒られたら
webrickは良く使うプログラムなので後ではまる前にopen-ssl-devel をインストール後、再度前回でのやり方を踏まえてRubyをインストールしなおした。

> yum install openssl-devel
...
...
Complete!
> cd /tmp/ruby-1.9.3-p392
> make clean
> ./configure --with-opt-dir=/usr/local/lib --with-opt-dir=/usr/lib64 --enable-shared --enable-option-checking
> make
....
....
configuring openssl
...
configuring zlib
...
...
linking shared-object openssl.so
installing default openssl libraries
...
...
compiling zlib.c
linking shared-object zlib.so
installing default zlib libraries
...
....
Files:        772

Classes:     1374 ( 708 undocumented)
Modules:      306 ( 152 undocumented)
Constants:   2258 ( 828 undocumented)
Attributes:  1020 ( 440 undocumented)
Methods:    10478 (3096 undocumented)

Total:      15436 (5224 undocumented)
 66.16% documented

Elapsed: 214.8s

> ruby -v
ruby 1.9.3p392 (2013-02-22) [x86_64-linux]

が、実際にopensslが使えるかどうか、irbで試してみると駄目と言われてしまう。何かが足りないらしい。

irb(main):001:0> require 'openssl'
LoadError: cannot load such file -- openssl
        from /usr/local/lib/ruby/1.9.1/rubygems/custom_require.rb:36:in `require'
        from /usr/local/lib/ruby/1.9.1/rubygems/custom_require.rb:36:in `require'
        from (irb):1
        from /usr/local/bin/irb:12:in `
'
irb(main):002:0> require 'zlib'
=> true   # zlibは問題ない

ここでopensslのスタティックライブラリをyumからインストールしてみる他、rubyのmake時にffi というモジュールが上手くリンクできていなかったのを思い出し、その両方を試してみることにした。確かにコンパイル後Linking という表示がでるのはスタティックリンクも想起させるので怪しいといえば怪しいし、ffiにしてもどうやらダイナミックリンクの仕組みを担う部品かもしれない。Githubを参照すると、ffi-devel というライブラリに依存関係があると記されている(https://github.com/ffi/ffi)

> yum install openssl-static.x86_64
> yum install libffi-devel.x86_64

上記インストール後、再度configure から始めてみたところ、遂に irb で require 'openssl'が通るようになった。

> irb
irb(main):001:0> require 'openssl'
=> true

ここまでくればrailsまでは一気である。

>gem install rails
....
....
> rails -v
Rails 3.2.13

どうやら上手いこと、インストールできたようだ。