TACATAKATACA BLOG

エンジニアな記事やデザインの記事を投稿してゆきます


【Ruby2.0.0 or 1.9.3 on Rails4.0】 Nokogiri 1.6.0 インストールできない?!

ことあってRuby on Railsを勉強することにしました。

時間はあるので、先ずRuby 2.0.0 & Rails 4.0チュートリアルをして、

下バージョンは後でやろう、ということで

入門としてRubu on Rails チュートリアル by Michael Hartl氏で勉強しておりました。

 

そのなかの第3章「ほぼ静的なページの作成」のbundle install --without productionをする部分でハマりました

 

厳密にいうと 

gem install nokogiri 

ではまりました。

 

Gemfileにあるnokogiri (1.6.0)をinstall するところで 

以下のエラーを吐かれました。

 

 

結論から言って、このエラーを改善するための解決策はこれです。

 

NOKOGIRI_USE_SYSTEM_LIBRARIES=1 gem install nokogiri

NOKOGIRI_USR_SYSTEM_LIBRARIES環境変数を1にすればよいのです。

 

今回解決にあたって参考にさせて頂いたサイトはこちらの

Nokogiri 1.6.0 のインストールが遅い件とその解決方法

です。

 

サイトに詳細がありますが、説明に必要な部分だけピックアップすると、

Nokogiri 1.6.0 では libxml2 および libxslt を同梱し、環境に合わせてビルドするようになった 

みたいです。

 

そこで、元々システムにあるlibxmlおよびlibxsltを利用して

nokogiriをinstallしようというのがこの環境変数の要(かなめ)なのです。

 

そしてこの記事では、これでもなぜか改善されない方にむけた項目を記述しました。

 

実は、このインストールが成功するまでかなり長い道のりをたどってきました。

libiconv libxml2 libxstl opensslをインストールしても改善しない上で、NOKOGIRI_USE_SYSTEM_LIBRARIES=1を設定してもインストールできない方は

gcc周りの設定といった環境設定をもう一度見直してはいかがでしょうか。

私は以下の設定が主な原因だったと考えています。

#export CFLAGS='-isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/

Developer/SDKs/MacOSX10.8.sdk -I/opt/local/include/X11 -arch i386'

#export LDFLAGS='-arch i386'

#export ARCHFLAGS='-arch i386'

#export RC_ARCHS="i386

これらが設定されていれば、一度これらをコメントアウトしてNOKOGIRI_USE_SYSTEM_LIBRARIES=1 gem install nokogiriを実行してみてはいかがでしょう。

また、

printenv 

をしてみて、PATHに何度も同じパスが設定(表示)されているようであれば

二重にシェルを起動(?)しているかもしれません。

これでパス周りがおかしくなっているかもしれません。(もしかしたら違うかもしれませんが、改善される方がよいかと思われます。)

それぞれ、以下の奮闘その③を参照してみてください。もしかすると助けになるかもしれません。

 

以下は、インストールまで色々奮闘しましたよーというお話で

Nokogiriがインストールできない事への解決策を提示するという本題とは少しそれていますが、良ければ見てみて下さい。

 

 

===============================================================

Mac OS X 10.8.5

rbenv + Ruby 2.0.0 or 1.9.3 + Rails and Nokogiri

zsh with iTerm 

奮闘その① : libiconv周りでエラー

libxml2周りでエラーがでたということで、 一番はじめ

NOKOGIRI_USE_SYSTEM_LIBRARIES=1 gem install nokogiriしたところ

libiconv周りでエラーが出たのです。

 

エラーのログを消してしまったので今回詳細は提示出来ませんが、

こんな感じ(Installing nokogiri 1.5.2)で

ざっくり

iconv_open()関数がiconv.hの中にありません。

というような内容のエラーが出てきました。

そっかーlibiconv入ってないんだなということで、何も考えずに

brew search libiconv

brew install libiconv

をして、link(brew link libiconv --force)したのですが一向に消えません。

(libiconvが入っていないがためのエラーならこれで消えるはずなのです。)

Macportsを調べてみると既にlibiconvは入っている。

Homebrew、Macports共にupdateを実行し

もう一度gem install nokogiriを実行。

失敗。

iconv.hの中にiconv_open()はあるのかということで確認をしてみたところきちんと定義されている。

ならばここはextconf.rbのミスか?!

ということで、

extconf.rb (~/.rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/nokogiri-1.6.0/ext/nokogiri/)を確認すると、

have_iconv?を発見。そこでエラーが出ていると判定しました。

 

unless以下を上のように無理矢理trueにして、直接

ruby extconf.rb  

すると別の謎のエラーが帰ってきました。(ログは破棄してしまいました・・・)

libiconvのせいじゃなさそうです。

もう、libiconvのことは一旦忘れることにしました。

 

奮闘その② : もう一度libxml2周りのエラーに立ち向かう

libxml2 libxsltをbrewでリンクすればいいという話をききつけ

 brew link  libxml2 libxslt --force  

をして、パスが通っているであろうシンボリックリンクを作ってもらいます。

そしてNOKOGIRI_USE_SYSTEM_LIBRARIES環境変数を設定せず

gem install nokogiri

 

まだあのlibxml2周りのエラーが出続けます。

 

 

HomebrewとMacportsの共存がいけないのか?

ということで、Homebrew一本でいくためにMacportsにはおさらば。

sudo rm /opt/local ~/macpotrs

そしてNOKOGIRI_USE_SYSTEM_LIBRARIES環境変数を設定せず

gem install nokogir

 

まだあのlibxml2エラーです。

原因はもっと深い部分にあるようです。そこで・・・

奮闘その③ : 環境の一新

プログラム自体は色々組んでいるのですが、まだまだMacに慣れていません。

でもPCは自分だけの環境で他の人関係ないし、全然動くからいいもんねーふっふーん。

とか確信犯で以下のような阿呆なことをしていました。

  • PATHは何も考えずごり押しで通してきた
  • 友達からもらったzshrcをそのまま使っていた(所々コメントアウト)
  • iTermの設定のみを使ってzshを起動していた
  • printenv?なにそれおいしいの
  • brew doctor とか忘れてたてへぺろ

環境設定から異臭がしていたのは流石に気になっていました。

多分設定がおかしいのだろうというのは薄々気づいていたので

エラーが直るのではという思いもこめて、ここで一度軽い環境整備に走りました。

 

先ず、気持ちをリセットし、もう一度きちんとはじめからやり直すために

Homebrewを入れ直しました。

 

Homebrewのアンインストールと再インストールを参考にさせていただくと、

上手くHomebrew関連のディレクトリやファイル等を削除、再インストールすることができました。

それでは、

brew doctor

一杯警告出てくる。

先ず、Homebrewをアンインストールしたとき

/usr/local/に  /binや/shareを残していた名残があることから出た警告が1つ。

これは

brew prune 

で綺麗にしてもらう。

他に、2つめのPython周りの警告と3つめの

Warning: Some directories in your path end in a slash 

の警告。

Python周りはとりあえず放っておいて、異常なのがWarning: Some directories in your path end in a slash。

「ImageMagicへのパス記述の最後が/で終わってるよー」

という内容で単純なミスに関する警告ですが

/opt/local/var/macports/software/ImageMagick/

/opt/local/var/macports/software/ImageMagick/

/opt/local/var/macports/software/ImageMagick/

/opt/local/var/macports/software/ImageMagick/

/opt/local/var/macports/software/ImageMagick/

/opt/local/var/macports/software/ImageMagick/

6つパス通してるって言うのです。

どう見てもおかしい。

そもそも、

ImageMagicはMacportsから入れたアプリケーションで、

.zshrcに記述してある

export PATH=/opt/local/var/macports/software/ImageMagick/:$PATH

MacPortsを~/macportsに入れた際にコメントアウトしたのです。(最後のスラッシュ(ImageMagick/)が今回の警告の原因です)

パスが通ってすらいないハズのものが通っていて、しかも6つも検知されている・・・

こいつ、.bashrcを読み込んでるわけでもあるまいし・・・

(これ、zshに乗り換えたときに.bashrcから直接.zshrcへコピペした部分の一部なのです。)

ぬう。Homebrew のお医者さん意味不明すぎるのでとりあえず置いておきましょう。

 

続けて、環境改善してゆきます。手始めに。

printenv 

 で設定を確認。

めちゃくちゃ出てくる。最も気になったのが、

/usr/local/bin

/usr/local/sbin 

 が2回も出てくる。おかしい。絶対おかしい。

しかも2回目の/usr/local/sbinの次の文字が文字化けしているww

 

さっきからPATH多重で通り過ぎ。

nokogiriが入らなかった原因の一つが

パスの問題かもしれない可能性がでてきました。

 

考えられる原因は

  • /etc/pathsに二重で書いてある
  • /etc/pathsに書いてあるから.zshrcでPATH通さなくてもよいのでは
  • zsh設定ファイルに加え、未だにbash設定ファイルを読み込んでる 

まず上二つを確認、改善。しかしまだ直らない。 

ということで、

原因を「zsh設定ファイルに加え、未だにbash設定ファイルを読み込んでる」にしぼりました。

(6つパスが通ってるという)brew doctorの警告文もこれが原因でしょうか。

まず、.bashrcファイルをなくします。

rm ~/.bashrc ~/bashrcsawp

printenvしてもまだ多重にパスが通っています。

もちろん、作業ごとにターミナルは再起動しています。

普段.bashrcにしかPATH記述していないからおかしい。

ここで、printenvの出力がおかしい事に気づく。

SHELL=/bin/bash 

zshじゃない?!

iTerm起動時にまずbash通ってzshを開いているようです。

 

私、iTermのプロファイルで/bin/zshコマンドで起動するよう設定すればよいだけだと勘違いしており、ここを完全に見過ごしていました。

ユーザ毎にシェル設定する必要があるみたいです。(私の勉強不足ですね) 

ということで、bashzshに変更

chpass -s /bin/zsh

 再起動して、SHELLを確かめると/bin/zshときちんと変更されました。

この状態でprintenvをすると.zshrcだけを上手く読み込んでくれていました。

zshを開く過程で.bashrc.bashrc_profileその他設定ファイルを読み込んでいる事が

多重パスの原因だったようです。

 

さて、ここでもう一度Homebrewのお医者さんに見てもらうことに。

brew doctor

 警告が「pythonにリンクしてね」のみになっており、

どうやら色々すっきりしたようです。かなり環境が改善されました。

 

 

さて、ここで話がもどって参ります。

rbenvと必要ライブラリたちをもう一度 インストールするのです。

brew install rbenv ruby-build libxml2 libxslt libyaml openssl

今度は手動でrubyをビルドしました

OSXでrbenvを使ってrbuy1.9.3 or 2.0.0の環境を作るを参考にしましたが

autoconfの部分でエラーが出てきました。

OS Xに入ってるautoconfのバージョンが2.6.8以上でない

(autoconf 2.6.8 or higher 的なエラーでした)

ということで、homebrewからbrew link --forceしましたが反映されず・・・

(この辺の設定まだよく分かってないんですよね・・・)

 

仕方なくこちらのシェルスクリプトからMacに入っているものを直接バージョンアップしました。

Install Autoconf and Automake on OS X Mountain Lion

このシェルスクリプトでは、aoutoconfの他にautomake、libtoolをインストールしていますが

どうせいつかまたこの辺でハマるかもと考え、 シェルスクリプトをそのまま実行し

autoconfと同時にautomake、libtoolもインストール、バージョンアップしました。

 

これで何のエラーもなく上手く行きました。

 

他に手動ではなく、rbenv installから

RUBY_CONFIGURE_OPTS="--with-readline-dir=$(brew --prefix readline) --with-openssl-dir=$(brew --prefix openssl)" rbenv install 2.0.0-p247

CONFIGURE_OPTS="--with-readline-dir=$(brew --prefix readline)" rbenv install 1.9.3-p448

も通るようになりました。

ところで、

#export CFLAGS='-isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/

Developer/SDKs/MacOSX10.8.sdk -I/opt/local/include/X11 -arch i386'

#export LDFLAGS='-arch i386'

#export ARCHFLAGS='-arch i386'

#export RC_ARCHS="i386"

 これらの設定をしているとrubyのmake時にエラーが出るのでこの設定をなくしてみると上手く行くかもしれません。

 

あと、

rbenv rehash 

も忘れずに!

 

==============================================================

 

ここまできて、ようやく  NOKOGIRI_USR_SYSTEM_LIBRARIESを利用した

NOKOGIRI_USR_SYSTEM_LIBRARIES=1 bundle install --without production

 でnokogiri(1.6.0)インストールが成功し、無事環境を整える事ができました。

 

私なりにNOKOGIRI_USR_SYSTEM_LIBRARIES=1 gem install nokogiriできない原因を考えました。

原因は、結局gcc周りなのだろうと考えました。

#export CFLAGS='-isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/

Developer/SDKs/MacOSX10.8.sdk -I/opt/local/include/X11 -arch i386'

#export LDFLAGS='-arch i386'

#export ARCHFLAGS='-arch i386'

#export RC_ARCHS="i386"

この設定がnokogiriのインストールを阻害していたのでしょう。

rubyのビルドの際にこの設定のせいでエラーが出ている事に気づきました。

設定をコメントアウトするとmakeに成功しました。

 

どの環境変数が妨げになっているのか、今の段階でまだ探りを入れてはいませんが、

警告を見る限り-arch i386を設定しているのが問題であるのは間違いないのです。

 

Homebrewをアンインストールするときにログも一気に掃除してしまったので

現在はエラーログを提示出来ませんが、

実はnokogiriのmkmf.logでも(i386に関する)gcc周りのエラーが出ていたのです。

このgcc周りのエラーが後に処理されるプログラムにおける

膨大な数のエラーや警告に繋がっており、

当時病んでいた私は

これが出力されているめちゃくちゃ長いlogファイルから

原因を突き止める気になれなかったのです。

完全に盲点でした。今見ても自分何してたんだろうとしみじみします。

 

ちなみにこの設定たちは

いつしかOS Xに入っているgccが動かなかった際に挿入したものだったり、

rbenvトラブルシューティングの一つで挿入したりして出来たものです。

 

環境変数は上手く活用すれば非常に便利ですが、

使いどころを見極めなければ毒となるといったところしょうか・・・

冷静になってみると、当たり前のことですね笑