cabal-pkg-config-version-hook should use Cabal Program API instead of hard coding pkg-config binary name

[sternenseemann]

In nixpkgs, pkg-config is prefixed in the cross case, so this would fail miserably:

https://github.com/hercules-ci/hercules-ci-agent/blob/master/cabal-pkg-config-version-hook/src/Distribution/PkgConfigVersionHook.hs#L154

We do already provide the correct pkg-config executable to Cabal via the --with-pkg-config flag, so it should be easily possible to obtain the correct program.

[roberth]

--with-pkg-config flag

#448 should help with that.

[roberth]

I will leave #448 unmerged state until it's validated. I haven't quite succeeded at that.

[domenkozar]

Using domenkozar/nixpkgs@369b2ec and running nix-build -A pkgsStatic.cachix --cores 1 I get:

[ 9 of 14] Compiling Hercules.CNix.Exception ( src/Hercules/CNix/Exception.hs, dist/build/Hercules/CNix/Exception.o )
ghc: internal error: /nix/store/yrvisx0g79p2s1pwizqvbb2w48g5hidv-x86_64-unknown-linux-musl-stage-final-gcc-11.3.0-lib/x86_64-unknown-linux-musl/lib/libstdc++.a: unhandled ELF relocation(RelA) type 23

    (GHC version 9.2.4 for x86_64_unknown_linux)
    Please report this as a GHC bug:  https://www.haskell.org/ghc/reportabug
/nix/store/3wqkajxdrvd04kymjd73gbd7dg7lrmdi-stdenv-linux/setup: line 1399:   329 Aborted                 (core dumped) ./Setup build --with-ghc=x86_64-unknown-linux-musl-ghc --with-ghc-pkg=x86_64-unknown-linux-musl-ghc-pkg --with-gcc=$CC --with-ld=x86_64-unknown-linux-musl-ld --with-ar=x86_64-unknown-linux-musl-ar --with-hsc2hs=x86_64-unknown-linux-musl-hsc2hs --with-strip=x86_64-unknown-linux-musl-strip --hsc2hs-option=--cross-compile --with-pkg-config=x86_64-unknown-linux-musl-pkg-config
error: builder for '/nix/store/crdsjs671m4jfm8yklkq9qizx1li29l6-hercules-ci-cnix-store-static-x86_64-unknown-linux-musl-0.3.3.3.drv' failed with exit code 134;
       last 10 log lines:
       > [ 5 of 14] Compiling Hercules.CNix.Std.String.Instances ( src/Hercules/CNix/Std/String/Instances.hs, dist/build/Hercules/CNix/Std/String/Instances.o )
       > [ 6 of 14] Compiling Hercules.CNix.Std.String ( src/Hercules/CNix/Std/String.hs, dist/build/Hercules/CNix/Std/String.o )
       > [ 7 of 14] Compiling Hercules.CNix.Store.Context ( src/Hercules/CNix/Store/Context.hs, dist/build/Hercules/CNix/Store/Context.o )
       > [ 8 of 14] Compiling Hercules.CNix.Settings ( src/Hercules/CNix/Settings.hs, dist/build/Hercules/CNix/Settings.o )
       > [ 9 of 14] Compiling Hercules.CNix.Exception ( src/Hercules/CNix/Exception.hs, dist/build/Hercules/CNix/Exception.o )
       > ghc: internal error: /nix/store/yrvisx0g79p2s1pwizqvbb2w48g5hidv-x86_64-unknown-linux-musl-stage-final-gcc-11.3.0-lib/x86_64-unknown-linux-musl/lib/libstdc++.a: unhandled ELF relocation(RelA) type 23
       >
       >     (GHC version 9.2.4 for x86_64_unknown_linux)
       >     Please report this as a GHC bug:  https://www.haskell.org/ghc/reportabug
       > /nix/store/3wqkajxdrvd04kymjd73gbd7dg7lrmdi-stdenv-linux/setup: line 1399:   329 Aborted                 (core dumped) ./Setup build --with-ghc=x86_64-unknown-linux-musl-ghc --with-ghc-pkg=x86_64-unknown-linux-musl-ghc-pkg --with-gcc=$CC --with-ld=x86_64-unknown-linux-musl-ld --with-ar=x86_64-unknown-linux-musl-ar --with-hsc2hs=x86_64-unknown-linux-musl-hsc2hs --with-strip=x86_64-unknown-linux-musl-strip --hsc2hs-option=--cross-compile --with-pkg-config=x86_64-unknown-linux-musl-pkg-config

[domenkozar]

Possibly related: https://gitlab.haskell.org/ghc/ghc/-/issues/17446

[sternenseemann]

Skimming that GHC issue it seems like it's unlikely this will ever work, since we have to use the RTS linker in pkgsStatic for a lack of dynamic objects. So it seems like it would only be possible to build cachix (as is) statically using static-haskell-nix which you should investigate.

Dodging the RTS linker could be done, though, if hercules-ci-cnix-store eliminated all TemplateHaskell, I'd imagine.

[roberth]

Eliminating TemplateHaskell amounts to rewriting the library. I'd support that as part of the effort to improve the nix bindings situation upstream.

It could be layered as follows and be contributed to NixOS/nix.

Haskell `module Nix.Store`
    |
    | calls
    v
hsc2nix code
    |
    | calls
    v
C functions
    |
    | calls
    v
Nix C++

The C functions could evolve into a stable interface that's shared between bindings, such as the new python bindings, but also the existing perl bindings.

Nix Team's thoughts on official python bindings:

• Experimental python bindings NixOS/nix#7735 (comment)