Cabal doesn't seem to call the correct hsc2hs when cross-compiling

[vmchale]

When trying to build cabal-install with the following:

cabal new-build --with-ghc arm-linux-gnueabihf-ghc --with-ghc-pkg arm-linux-gnueabihf-ghc-pkg --with-hsc2hs=hsc2hs

I end up with

Build profile: -w ghc-8.6.2 -O1
In order, the following will be built (use -v for more details):
 - hackage-security-0.5.3.0 (lib) (requires build)
 - zip-archive-0.3.3 (lib:zip-archive) (requires build)
 - cabal-install-2.4.1.0 (exe:cabal) (first run)
Starting     zip-archive-0.3.3 (all, legacy fallback)
Starting     hackage-security-0.5.3.0 (lib)

Failed to build hackage-security-0.5.3.0. The failure occurred during the
configure step.
Build log (
/home/vanessa/.cabal/logs/ghc-8.6.2/hackage-security-0.5.3.0-49090b92e0c750f4f930f2057bed30927690037cb7d641f2fc7635fb9e5d0d07.log
):
Configuring library for hackage-security-0.5.3.0..
cabal: The program 'hsc2hs' version >=0.67 && <0.69 is required but the
version of
/home/vanessa/.cabal/store/ghc-8.6.2/hsc2hs-0.68.4-23e7a5612c9d790260d1fbf5570d20d2b91321b3d84ff9e3ff4190c9bc8332b0/bin/hsc2hs
could not be determined.

cabal: Failed to build hackage-security-0.5.3.0 (which is required by
cabal-install-2.4.1.0). See the build log above for details.
Failed to build zip-archive-0.3.3 (which is required by
cabal-install-2.4.1.0). The failure occurred during the configure step. The
build process terminated with exit code 2

I believe this may be due to the fact that hackage-security actually specifies a dependency on hsc2hs. zlib, digest, and network all build fine and their .cabal files don't seem to mention any build-tool-depends anywhere.

Here is the call stack:

CallStack (from HasCallStack):
  die', called at ./Distribution/Simple/Program/Db.hs:484:18 in Cabal-2.4.1.0-2mL6d3JeEJ7DKvehaV04FE:Distribution.Simple.Program.Db
  requireProgramVersion, called at ./Distribution/Simple/Configure.hs:1493:30 in Cabal-2.4.1.0-2mL6d3JeEJ7DKvehaV04FE:Distribution.Simple.Configure
  configureRequiredProgram, called at ./Distribution/Simple/Configure.hs:1434:10 in Cabal-2.4.1.0-2mL6d3JeEJ7DKvehaV04FE:Distribution.Simple.Configure
  configureRequiredPrograms, called at ./Distribution/Simple/Configure.hs:578:11 in Cabal-2.4.1.0-2mL6d3JeEJ7DKvehaV04FE:Distribution.Simple.Configure
  configure, called at ./Distribution/Simple.hs:596:20 in Cabal-2.4.1.0-2mL6d3JeEJ7DKvehaV04FE:Distribution.Simple
  confHook, called at ./Distribution/Simple/UserHooks.hs:67:5 in Cabal-2.4.1.0-2mL6d3JeEJ7DKvehaV04FE:Distribution.Simple.UserHooks
  configureAction, called at ./Distribution/Simple.hs:178:19 in Cabal-2.4.1.0-2mL6d3JeEJ7DKvehaV04FE:Distribution.Simple
  defaultMainHelper, called at ./Distribution/Simple.hs:120:19 in Cabal-2.4.1.0-2mL6d3JeEJ7DKvehaV04FE:Distribution.Simple
  defaultMainArgs, called at main/Main.hs:1238:18 in main:Main

[hvr]

is the executable at /home/vanessa/.cabal/store/ghc-8.6.2/hsc2hs-0.68.4-23e7a5612c9d790260d1fbf5570d20d2b91321b3d84ff9e3ff4190c9bc8332b0/bin/hsc2hs a crosscompiled one?

[vmchale]

Yes, that is correct.

vanessa@thinkpad ~/programming/haskell/done/xmonad-vanessa 🌸 file /home/vanessa/.cabal/store/ghc-8.6.2/hsc2hs-0.68.4-23e7a5612c9d790260d1fbf5570d20d2b91321b3d84ff9e3ff4190c9bc8332b0/bin/hsc2hs
/home/vanessa/.cabal/store/ghc-8.6.2/hsc2hs-0.68.4-23e7a5612c9d790260d1fbf5570d20d2b91321b3d84ff9e3ff4190c9bc8332b0/bin/hsc2hs: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 3.2.0, BuildID[sha1]=f0e6415adf9d79c0c5b5007f147b48fb08c89da5, with debug_info, not stripped

[vmchale]

Incidentally, Cabal seems to work just fine when cross-compiling and using cpphs, even when cpphs is listed under build-tools.

[vmchale]

As a temporary workaround, using --with-hsc2hs=home/vanessa/.cabal/bin/hsc2hs (i.e. passing the absolute path) seems to work.

[hvr]

Yeah, so the problem is that we don't have a proper separation of build-host vs target-host artifacts in the build-planning; iirc there's been some prior discussion about this problem somewhere buried in the issue tracker. The obvious model would be that stuff being executed at compile time (build-tools, pre-processors, or even TH -- this is the most tricky one) needs to be runnable on the build-host w/o requiring anything to be run on the target-host (cause in most scenarios you're crosscompiling because you don't have the target-host available or for some other reason it's unreasonable to build directly on it)