ROOT のビルド

比較的制限の強いサーバー環境下で ROOT を自前でビルドした時のメモ。

先日の GCC の続き。
次いで慣れているはずの ROOT をビルドししようとしたところ、
多くのライブラリを自前で用意したり、ネットワークで外に接続できないことに起因して、
色々とハマりまくったのでその時のメモ。

同様の制限下で、全く同様に ROOT をビルドするという状況はほぼ皆無とは思いつつも、
各所の対処方法は、個別の問題のトラブルシューティングになると思ったので公開。

環境

前回の繰り返しになるが、環境のサマリー。

OS : Red Hat Enterprise Linux Server release 6.7 (Santiago)
枯れているというか、古い。
ネットワークは強く制限されていて、外部への通信は不可。
外部からの接続は中継を乗り継いでログインする。- ユーザー権限のみ。クラスタ管理者は全く頼れない。
ライブラリなど
レポジトリは古く、そもそも各種開発用パッケージが入っていない。
上記ネットワークの制約からそもそも yum 等のパッケージマネージャーが機能しない。

というわけで、基本は外部から必要なものを持ち込んで、
必要ならば基本的なライブラリから全て自分でビルドして、
ユーザー領域下に自分専用システムを構築していく感じになる。

ネットワークがキツくなければ linuxbrew とかで簡単にできるのだけどね。。。

binutils

この時点で最新リリース v2.31.1 が公開から半年近く経っているので、
大丈夫だろうと思ったのでビルドして組み込んだら、
後段の ROOTビルド時に ld がエラーを吐いたので、v2.30 に戻って作り直した。

v2.31.1 でハマったエラー以下のような感じ

/path/to/ld: lib~.so: __bss_start: invalid version 21 (max 0)
lib~.so: error adding symbolsL Bad value

/path/to/ld: lib~.so: __bss_start: invalid version 21 (max 0)

lib~.so: error adding symbolsL Bad value

ググりまくったら、2018/08 初旬に同様の症状を訴えている開発者のやり取りを発見。
そこでは、何らかのパッチを適用すれば治るとコメントがあった。
v2.31.1 の公開日 2018/07中旬なので、このversionはバグありと判断して数字を戻した。

ビルド自体はシンプルで、以下のように普通通り。
--prefix で自分のユーザー領域下を指定するのを忘れないように。

./configure --prefix=~/path/to
make -j N
make install

./configure --prefix=~/path/to

make -j N

make install

gcc

GCC のビルドはコチラ。

libXpm

こいつは自分でビルドする人がほとんどいないようで、
そもそもどこからソースをダウンロードすれば良いのかしばらく迷った。
libXpm とか入れても GitHub上の個人のフォークみたいなものしか見つからず、
最終的にようやく xorg の archive 下からダウンロードできた。
https://www.x.org/archive//individual/lib/

ビルド自体は通常通り。

cmake

自前の gcc でビルドする場合は、
自前の libstdc++.so 等とリンクさせてやらなければならないので、
LDFLAGS で自作 gcc 下の lib を指定してやる必要がある。

LDFLAGS="-L/path/to/gcc/lib64" ./bootstrap --prefix=/path/to/cmake --parallel=32
make -j 32
make install

LDFLAGS="-L/path/to/gcc/lib64" ./bootstrap --prefix=/path/to/cmake --parallel=32

make -j 32

make install

ROOT

ここまでは全てこの ROOT をビルドするための下準備。
これでようやくビルドできると思ったらまだまだハマりどころが。

ビルドするのは v6系。
configure でもビルドできるようだが、
近くサポート外になりそうなので、cmake でビルドする。

cmake でインストール先を指定

./configure --prefix=/path/to/install 的なの。

$ cmake [src] -DCMAKE_INSTALL_PREFIX=/path/to/install ...

1 2	$ cmake [src] -DCMAKE_INSTALL_PREFIX=/path/to/install ...

cmake の find_package で自前のライブラリを見つけさせる

今回なら libXpm の入っている親ディレクトリ（配下に bin, lib, include がある）を指定。

$ cmake ... -DCMAKE_PREFIX_PATH=/path/to/libXpm ...

1 2	$ cmake ... -DCMAKE_PREFIX_PATH=/path/to/libXpm ...

これで find_package(X11 Required) が自前の libXpm を見つけてくれるようになる。

python の指定

PyROOT とリンクする python を指定。
これまたシステムのは化石みたいのしか入っていないので、
自前のところを参照させる（導入は割愛）。

$ cmake ... -DPYTHON_EXECUTABLE=/path/to/python/exe -DPYTHON_INCLUDE=/path/to/Python.h/dir

1 2	$ cmake ... -DPYTHON_EXECUTABLE=/path/to/python/exe -DPYTHON_INCLUDE=/path/to/Python.h/dir

-DPYTHON_EXECUTABLE: pythonコマンド本体のパス（親dirではない）を指定。
-DPYTHON_INCLUDE: 対応する Python.h を含むディレクトリまでのパス。
今回の環境の例では ~/.../python3/include/python3(/Python.h) のように、
include 止まりではなかったので注意が必要（１敗）。

自前の gcc 下のライブラリを参照させる

前述の cmake のビルド時と同様、自前の gcc でビルドする際は、
自前の gcc下のライブラリとリンクさせてやる必要がある。
LDFLAGS に相当するものの指定は以下の通り。

$ cmake ... -DCMAKE_EXE_LINKER_FLAGS="-L/path/to/gcc/lib64" -DCMAKE_SHARED_LINKER_FLAGS="-L/path/to/gcc/lib64"

1 2	$ cmake ... -DCMAKE_EXE_LINKER_FLAGS="-L/path/to/gcc/lib64" -DCMAKE_SHARED_LINKER_FLAGS="-L/path/to/gcc/lib64"

前者は実行ファイルと、後者はshared libとリンクさせる際のフラグを指定。
今回の ROOT のビルド時に両方ともに必要かは知らないが、少なくとも両方無しではコケる。
64bit 環境の場合は .../gcc/lib でもないので注意（１敗）。

cmake コマンドまとめ

以上を全てまとめるとこんな感じになるはず。

cmake [src] -DCMAKE_INSTALL_PREFIX=/path/to/install -DCMAKE_C_COMPILER=gcc -DCMAKE_CXX_COMPILER=g++ -DCMAKE_PREFIX_PATH=/path/to/libXpm -DPYTHON_EXECUTABLE=/path/to/python/exe -DPYTHON_INCLUDE_DIR=/path/to/Python.h/dir -DCMAKE_EXE_LINKER_FLAGS="-L/path/to/gcc/lib64" -DCMAKE_SHARED_LINKER_FLAGS="-L/path/to/gcc/lib64"

cmake [src] -DCMAKE_INSTALL_PREFIX=/path/to/install -DCMAKE_C_COMPILER=gcc -DCMAKE_CXX_COMPILER=g++ -DCMAKE_PREFIX_PATH=/path/to/libXpm -DPYTHON_EXECUTABLE=/path/to/python/exe -DPYTHON_INCLUDE_DIR=/path/to/Python.h/dir -DCMAKE_EXE_LINKER_FLAGS="-L/path/to/gcc/lib64" -DCMAKE_SHARED_LINKER_FLAGS="-L/path/to/gcc/lib64"

あとは、-DCMAKE_C(XX)_FLAGS のビルド最適化オプションやら、
ROOT サブモジュール（？）のビルドのスイッチ（-DXXXX=ON）やらを適宜追加。
詳細はこの辺りに載っている。

cmake の file(DOWNLOAD ...)

これまで何度も行っているはずの ROOT のビルドで一番驚いたのはコレ。
GSL, FFTW など builtin_xxx という形で内包されるものは、
ビルド時にソースをダウンロードしに行っていた。
対応するコマンドは cmake なら file(DOWNLOAD ...) のようだ。

前述の通り、今回の環境は外には出られないので、細工無しには動かない。
ご丁寧に一時領域DL、ハッシュ確認、使用後削除とかあれこれしているので、
自分で事前にダウンロードしておくというのも、なかなかに複雑で面倒。
そこで以下のようにして SSH 経由で外に出してやることにした。

以下は塞がれているはずのネットワークに
穴を開けるセキュリティリスクになる方法なので、
悪用厳禁、サーバー管理者に怒鳴られても責任は取りません。
（多分後で、別記事にする）

接続元: $ ssh -R xxxxx:localhost:22 server_address
接続先: (何らかのターミナルを別窓で開いておく)
接続先: $ ssh -p xxxxx -D XXXXX localhost
接続元: $

接続元: $ ssh -R xxxxx:localhost:22 server_address

接続先: (何らかのターミナルを別窓で開いておく)

接続先: $ ssh -p xxxxx -D XXXXX localhost

接続元: $

１行目は後で接続先サーバーから、接続元の自機にログインできるようにするおまじない。
３行目：１行目で指定した localhost:xxxxx に向かってssh, 自マシンにログインできる。
（自機の sshd設定等は割愛。これが通ら(せられ)ない方は真似しないほうが良いと）
この時に -D オプションで、自マシンを socks proxy として指定する。
httpリクエストなどを、接続先サーバーから接続元自マシンへ流して外に出せるようにする。
３行目で端末が接続元に帰ってきてしまうので、２行目で別端末を開いておいた訳ですね。
-f が使えるけど、この接続を後で切り忘れると騒動になりかねないのでオススメはしない。

この状態で接続先サーバー側から、例えば curl なら
$ curl --tlsv1.2 --socks4 localhost:XXXXX とすれば http/https で外に出られる。
他は http_proxy なり all_proxy なりを参照してくれるコマンド類なら通るようになる。
(環境変数はいずれも小文字）

export http_proxy="socks4://localhost:XXXXX"
export all_proxy="socks4://localhost:XXXXX"

export http_proxy="socks4://localhost:XXXXX"

export all_proxy="socks4://localhost:XXXXX"

今回の cmake の file(DOWNLOAD ...) がどうだったかというと。。。ＯＫ！！
どちらの環境変数が効いたのかは、試してないので知らない。