Building from source
ビルドに必要なものをインストールします。自分の環境に必要なものだけ入れてください。
sudo apt-get install gcc g++ make autoconf automake libtool
sudo apt-get install libpng-dev libjpeg-dev libgif-dev
sudo apt-get install libssl-dev libyaml-dev libsqlite3-dev libleveldb-dev
Ubuntu 12.04では、libleveldb-devのバージョンが古すぎて対応していないので、最新のバージョンをソースから入れてください。1.5以上が必要です。 install-leveldb
sudo apt-get install libpq-dev
sudo apt-get install libmysqlclient-dev
sudo yum -y install make gcc gcc-c++ autoconf automake libtool
leveldb-develがEPELにしかないのでEPELを有効にします。
curl -O http://ftp-srv2.kddilabs.jp/Linux/distributions/fedora/epel/6/x86_64/epel-release-6-8.noarch.rpm
sudo rpm -ivh epel-release-6-8.noarch.rpm
sudo yum -y install libpng-devel giflib-devel libjpeg-devel
sudo yum -y install openssl-devel leveldb-devel sqlite-devel libyaml-devel
sudo yum -y install postgresql-devel
sudo yum -y install mysql-libs mysql-devel
gcc4.2はコンパイル時に Internal Error が出るので、新しめのgccを入れておきます。 Clangのシステム(FreeBSD 10系)でも、ClangはOpenMPに対応していないのでgccをインストールします。
sudo pkg_add -r automake autoconf libtool
sudo pkg_add -r gcc49
ビルド周りの環境変数を設定します。
setenv CC gcc49
setenv CXX g++49
setenv C_INCLUDE_PATH /usr/local/include
setenv CPLUS_INCLUDE_PATH /usr/local/include
setenv LIBRARY_PATH /usr/local/lib:/usr/local/lib/gcc49
setenv LD_LIBRARY_PATH /usr/local/lib/gcc49
LD_LIBRARY_PATHにコンパイルに使ったgccのライブラリパスを設定しないと、実行時にシステムのlibgompを読んでエラーが出ます。
sudo pkg_add -r png jpeg giflib-nox11
sudo pkg_add -r libyaml sqlite3 leveldb
sudo pkg_add -r postgresql90-client
sudo pkg_add -r mysql55-client
Command Line Tools for XCodeとhomebrewはインストール済みとします。システムのClangはOpenMPが使えないのと、apple-gcc42は想定しているオプションと非互換があるので、gcc48をインストールします。
brew install autoconf automake libtool
brew tap homebrew/versions
brew install gcc48
ビルド周りの環境変数を設定します。
export CC=gcc-4.8
export CXX=g++-4.8
brew install libpng jpeg giflib
brew install leveldb libyaml
画像の読み込みライブラリ eiio をインストールします。
curl -OJL https://github.com/nagadomi/eiio/archive/v0.5.7.tar.gz
tar -xzvf eiio-0.5.7.tar.gz
cd eiio-0.5.7
./autogen.sh
./configure
make
sudo make install
sudo ldconfig
画像処理や数値計算のライブラリ nv をインストールします。
curl -OJL https://github.com/nagadomi/nv/archive/v2.2.1.tar.gz
tar -xzvf nv-2.2.1.tar.gz
cd nv-2.2.0
./autogen.sh
./configure
make
sudo make install
sudo ldconfig
otamaをインストールします。make checkでotamaのテストが走ります。
curl -OJL https://github.com/nagadomi/otama/archive/v0.7.6.tar.gz
tar -xzvf otama-0.7.6.tar.gz
cd otama-0.7.6
./autogen.sh
./configure
make
make check
sudo make install
sudo ldconfig
otamaのRuby拡張ライブラリのターゲットとするRubyインタプリタを指定します。ruby19などコマンド名にバージョンが入っている場合は、--with-ruby=ruby19 と指定してください。
またRuby拡張ライブラリのビルドには、Rubyのヘッダファイルやmkmfが必須なので ruby-devなどの開発パッケージをあらかじめインストールしておいてください。
otamaのRuby拡張を無効にします。
生成されるバイナリのターゲットCPUを指定します。native、generic、またはgccの-marchオプションで指定可能な値を指定します。
デフォルトはnativeになっています。nativeだとコンパイルした環境のCPUで使える命令は使うので、異なるCPUでは動かないバイナリが生成される場合があります。Debian Packageなど一般的な環境で動くバイナリを作る必要のある場合はgenericを指定してください。ただし、genericを指定した場合、一部のドライバで性能が著しく低下します。
Aamazon EC2やVPSなどの仮想環境において、--with-arch=nativeだと動かないことがあるようです。これはgccから見えているCPUの命令セットとVirtual Machineが実行できる命令セットに不整合があるためAVXなど新しいめの命令を使ってコンパイルされたバイナリが動かないという症状のようです。
- コンパイル時に
no such instructionエラーが出る - 実行時に
Illegal Instruction例外が出る
場合は、eiio、nv、otama、それぞれのconfigureで --with-arch=corei7や--with-arch=core2 など互換性のある下位のCPUを指定してみてください。
Intel/AMD CPUのPOPCNT命令を有効にします。Intel CPUの場合、--with-archオプションでPOPCNTに対応しているアーキテクチャを指定すると自動で有効になっていますが、一部のAMD CPUでは、POPCNTが有効にならないので明示的に指定できるようにしています。POPCNT命令が使えると、一部のドライバの性能が4〜10倍程度よくなります。
指定するとPostgreSQLのサポートが有効になります。otamaのビルドにはlibpqが必須になります。
otamaの設定で、
database:
driver: pgsql
と指定するとPostgreSQLのDBIが使われます。
指定するとMySQLのサポートが有効になります。otamaのビルドにはlibmysqlclientが必須になります。
otamaの設定で、
database:
driver: mysql
と指定するとMySQLのDBIが使われます。
指定するとSQLite3のサポート(デフォルト)が無効になります。
指定するとLevelDBのサポート(デフォルト)が無効になります。idドライバは、LevelDBを使ったbovw512k_iv_ldbではなくオンメモリ転置インデックスを使ったbovw512k_ivのエイリアスに変わります。Otama KVS APIもなくなるので、exampleなどが動かなくなります。
指定するとOpenMPのサポート(デフォルト)が無効になります。OpenMPに対応していないコンパイラを使いたい場合や、otama側で並列処理をしてほしくない場合に指定します。ただし、指定すると全体的な性能が著しく低下します。
デバッグ用のシンボルと実行時のアサーションを有効にし、コンパイラ最適化オプションを無効化します。デバッグ用。
OS XやFreeBSD 10などClangの環境が増えてきています。 いまのところotamaはClangには対応していません。理由はClangがOpenMPに対応していないからです。ClangにOpenMPの対応が入るとotama側も対応すると思います。
Clangの環境でgccを使ってotamaをビルドすると問題が出る場合があります。いまのところ気づいているのは、
- libyamlがFILE*を関数のインターフェースに使っているのでlibyamlとotamaで異なるC標準ライブラリをリンクしている場合にFILE構造体に互換性がなくstdioまわりが壊れる
です。libyamlもgccでビルドしなおせば動くと思います。
他にLevelDBのC++ APIを使っている場合に、std::stringに互換性がないという問題もありましたが、これは対応済みです。(C APIを使うようにした)