haskell-jp / nix #3 at 2021-10-02 12:48:52 +0900

こんなcontribution guideを敷いているリポジトリーにPull requestを送ろうとしたんですが、Nixをインストールして nix-shell したところ、多くのパッケージを何時間もかけてコンパイルしようとして結局失敗してしまいました（申し訳なくも失敗の正確な原因はつかめてません）。こういうとき、そもそもこれだけのためにわざわざコンパイルするのが苦痛なんでなんとか省略する方法はないのでしょうか？Cachixというのを使えばいいんですかね？
https://github.com/NorfairKing/sydtest/blob/master/CONTRIBUTING.md

ご認識の通りcachixをいれれば解決かと思います。
https://github.com/NorfairKing/sydtest/blob/master/.github/workflows/nix.yaml#L39-L44
github-actionsでもcachixつかっていますね。
6分くらいで終わるようです。

nix-env -i cachix
cachix use sydtest

を実行したあとに`nix-build`を実行ですかね。
ただこのキャッシュがubuntu向けのようなのでmacosで実行した場合はキャッシュはないでしょうね。

私は問題の調査方法として次のコマンドを実行して
失敗した/nix/store/*.drvの問題を調べています。

```#drvの環境に入る
nix-shell "失敗したdrvへのパス"

#build用の設定の読み込み
source $stdenv/setup

#エラーがでてもdrvの環境から抜けないようにする
set +e

#build
genericBuild```

あとはビルドのログの確認ですが、次のようにして確認できます。

nix log "drvへのパス"

詳しい回答ありがとうございます！！
今はDebianを使っているのですが、sydtestのGitHub Actionsが利用しているキャッシュをそのまま利用する場合はUbuntuにした方がいいのでしょうか？

キャッシュはx86_64-linuxやx86_64-darwinなど実行するアーキテクチャごとなので、debianのままで大丈夫です。

本件続報です。cachixをインストールしようとして気づいたのですが、どうも当初からこちらの問題にハマっていたのではないかと思います。
https://discourse.nixos.org/t/nix-build-trying-to-build-basic-tools-for-all-packages-from-scratch/11097/2
で、解決策曰くconfiguration.nixの nix.trustedUsers という項目をいじれ、とのことなのですが、 find / -name configuration.nix してみても該当のファイルが見当たりませんでした。どこに置いてあるのでしょうか？

/etc/nix/nix.conf

こちらですかね。
configuration.nixはnixosの場合の設定ファイルです。

ありがとうございます！やっぱそれなんですかね。構文が全く違うのでどう編集したものかと困惑してましたが...

あと

    - uses: cachix/cachix-action@v8
      with:
        name: sydtest
        extraPullNames: yamlparse
        signingKey: '${{ secrets.CACHIX_SIGNING_KEY }}'

となっていてextraPullNamesのところもサーバーのようですね。
なので

cachix use sydtest
cachix use yamlparse

の二つが必要ですね。

ようやくnix-shellができました！ありがとうございます！

ようやくnix-shellを起動して必要なものをインストールできたのでCONTRIBUTING.md の指示どおりnix-shellで stack test --pedantic したところ、こんなエラーが

 <command line>: /nix/store/ikl21vjfq900ccbqg1xasp83kadw6q8y-glibc-2.32-46/lib/libc.so.6: symbol _dl_fatal_printf version GLIBC_PRIVATE not defined in file ld-linux-x86-64.so.2 with link time reference

検索して見つかった https://stackoverflow.com/questions/49245547/version-glibc-private-not-defined-in-file-ld-linux-x86-64-so-2 を読んだところ、元々DebianにインストールされていたglibcとNixが入れたglibcとで競合しているために発生しているようです。
どなたか直し方に心当たりありませんか？

実は僕もいま同じ問題をかかえていて
どうやって直したものかと思っていました。
https://github.com/hasktorch/hasktorch/pull/619/checks?check_run_id=3776938349#step:10:1080

こんなページがあって、ここでは対象の実行ファイルに対して patchelf ってコマンドを使ってますね。私の場合どのコマンドかさえイマイチわからなかったのでちょっと試せてないのですが...
https://newbedev.com/how-to-use-libraries-installed-by-nix-at-run-time

patchelfはデフォルトのローダーやライブラリのリンクをかえるものですね。
例えば、ubuntuのlsのローダーは/lib64にあるものになりますが

$ patchelf --print-interpreter /usr/bin/ls
/lib64/ld-linux-x86-64.so.2

nixでビルドすると

$ patchelf --print-interpreter ./result/bin/cpod
/nix/store/2jfn3d7vyj7h0h6lmh510rz31db68l1i-glibc-2.33-50/lib/ld-linux-x86-64.so.2

こちらのようにnixの用意したローダーに書き換えられます。

libcで競合するなら、なにもかも動かなくなる気がしますが、
特定のケースだけなぜ動かないのかよくわからないですね。

参照するべきライブラリがわかっているなら
なにか実行するまえに下記を実行したらいいはずです。
（今回なにをみるべきかよくわからないです。）

export LD_PRELOAD=参照したいライブラリ

とりあえず、自分の問題のほうは、
よくわからないですが、既存のファイルの影響を排除するため
~/.stackと.stack-workのあたりを消してみて再実行してみます。
...
再実行してもだめでしたね。

GLIBC_PRIVATEに関するメモ。
https://groups.google.com/g/uk.comp.os.linux/c/PX3rstGtZRQ?pli=1

~/.stack/programs/x86_64-linux-nix/ghc-8.10.4/lib/ghc-8.10.4/bin/ghc

ここにあるghcがつかわれるようですが、nixが用意したldじゃなくてシステムのデフォルトが使われているのが原因のようですね。

nix-shellがghcを用意しているのに、

ghcをダウンロードしてダウンロードしたほうをつかおうとしますね。
stackのバグですかね。

--system-ghc をstackに加えればいいんじゃないでしょうか。そうでないならその挙動は仕様な気がします。それにしてもやっぱりNixOSなしのNix（あるいは、Nixの外である程度環境を整えた状態でのNix）は混乱の元ですね... :weary:

これはそれによらないと思いますね。
結局ダウンロードするので。

じつはstackとnixを両方使っているユーザーをあまり見たことがないですね。

nixと素のcabalだけ使う人はよく見ますが。あまりデバッグがされてない気がします。

stack test --pedantic --system-ghc

これでビルドできましたね。

ありがとうございます。

こちらこそ詳細の調査ありがとうございました！

僕の抱えていた問題もおなじでした。
ただ、--system-ghcはstackの要求するghcのバージョンとsystemにインストールずみのghcのバージョンが一致する場合だけ有効なようです。
そうでないと勝手にダウンロードしてきますね。