stackで行く地獄巡りの旅
Haskell使い 十戒
一、常に型と共にあれ
一、不要な式より潰すなかれ
一、無益にIOするなかれ
一、つけられたらつけかえせ
一、つけられる前につけろ
一、一日一善
一、遅延を疑ってみよ
一、気を付けよ甘い型付けと暗い道
一、小さなコードで大きな仕事
一、あがめよ讃えよ汝の師匠
チャララララー チャララララー チャララーラ ラーラ ラーララー ラララー
この記事はHaskell Advent Calendar 2015 - Qiitaの2日目の記事です.
今回は,stackにも使い慣れてきてそろそろhellが恋しくなってきた方々のため,stackに頼りつつもhellを拝むための方法を紹介する.ここでとりあげてるstackは0.1.6.0時点なので,後々なら何か変わってるかも
やり方はとても簡単で,システムghcの依存するパッケージバージョンがstackのresolverに含まれるものとズレている場合,--system-ghc使っていれば(つまりデフォルトで)既にあなたは地獄に来ている.やったぜ
たとえば,gentooのghc-7.10.2-r1.ebuildではtransformers-0.4.3.0が使われる.しかし,ghc-7.10系resolverであるlts-3ではtransformers-0.4.2.0が使われる.すると,transformersを使うパッケージをビルドするときに,
Warning: This package indirectly depends on multiple versions of the same package. This is highly likely to cause a compile failure. package transformers-compat-0.4.0.4 requires transformers-0.4.2.0 package primitive-0.6.1.0 requires transformers-0.4.2.0 (snip.) package QuickCheck-2.8.1 requires transformers-0.4.2.0 package ghc-7.10.2 requires transformers-0.4.3.0
のように,package DBに複数バージョンの同一パッケージがある状態でビルドが行われてしまう.モノによっては関数とかインスタンスとか型とか見つからなかったりしてコンパイルエラーを生じる.
他にも,システムghcの依存するパッケージバージョンが同じだったとしても,あるディレクトリで--no-system-ghc,別のディレクトリでは--system-ghcを使ったりすると条件によっては壊れる.今のstackは同一のpackage DBに--system-ghcのものも--no-system-ghcのものも区別せずに放り込んでしまう.本来はこれらの条件でも分離しておかなければならないように思う.
あとは,たぶんシステムにフラグ付きのパッケージをデフォルト以外のフラグ設定でインストールして使ってる場合もhellってないか注意が必要となる.
とりあえずstackを使ってhellを見ないようにするためには必ず--no-system-ghcで使うという決め打ちが必要になる.しかし,今lts-3系の--no-system-ghcでダウンロードされてくるghc-7.10.2バイナリの場合,環境によっては次の問題に当たってしまって使えないことがあったりする.
$ stack setup The GHC located at /home/notogawa/.stack/programs/x86_64-linux/ghc-7.10.2/bin/ghc failed to compile a sanity check. Please see: https://github.com/commercialhaskell/stack/blob/release/doc/install_and_upgrade.md for more information. Exception was: Running /home/notogawa/.stack/programs/x86_64-linux/ghc-7.10.2/bin/ghc /tmp/stack-sanity-check10231/Main.hs -no-user-package-db exited with ExitFailure 1 [1 of 1] Compiling Main ( /tmp/stack-sanity-check10231/Main.hs, /tmp/stack-sanity-check10231/Main.o ) Linking /tmp/stack-sanity-check10231/Main ... /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/../../../../x86_64-pc-linux-gnu/bin/ld: /tmp/stack-sanity-check10231/Main.o: relocation R_X86_64_32S against `stg_bh_upd_frame_info' can not be used when making a shared object; recompile with -fPIC /tmp/stack-sanity-check10231/Main.o: error adding symbols: Bad value collect2: エラー: ld はステータス 1 で終了しました
こういった環境では,むしろstack自体を使わないほうがいいまである.というか事実上使えない.
恐らく今後各ディストリビューションで用意するghcも積極的にstackageに合わせた依存関係にシフトするだろうし,--system-ghcについてだけ言えば過渡期にのみ生じるトラブルかもしれない.というか,ghc-7.10系のパッケージ持ってるディストリビューションが今現在そもそもそんなに多くないかもしれない.ただ,自分だけかもしれないとはいえ実際割と踏んでしまうことがある上,stackは特にこの業界では何故こんな名前にしたのか正気を疑う程に検索性の低いワードであるため,トラブル情報を漁るのも大変だ.備えよう.