#15758: hsc2hs broken due to incorrect argument passing to the hsc2hs executable -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ckoparkar): Here's another way to reproduce the build failure. If we create a 'Foo.hsc' file, and use {{{hsc2hs}}} built by HEAD to process it via a response file, it fails with the same error. {{{#!haskell -- Foo.hsc main :: IO () main = print $ #size int }}} {{{#!sh $ cat cmd_opts Foo.hsc }}} {{{#!sh $ ~/ghc/inplace/bin/hsc2hs @cmd_opts hsc2hs: @cmd_opts: openBinaryFile: does not exist (No such file or directory) }}} And this would always fail if HEAD is built with GHC < 8.6. I think that it's because in the GHC build system, {{{hsc2hs}}} is built during Phase 0, by the bootstrapping compiler. So if HEAD is bootstrapped with GHC < 8.6, it uses a version of {{{base}}} which does not support response files, and triggers a CPP codepath which does not know how to parse {{{@file}}} command-line arguments. So {{{hsc2hs}}} tries to read a '@file', which does not exist. I am unsure what right solution for this is. We certainly can't move {{{hsc2hs}}} out of 'Phase 0' as some artifacts in 'Phase 1' depend on it. Maybe the final {{{hsc2hs}}} executable that's generated under 'ghc/inplace' could be regenerated in a later phase. What do other people think about this ? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15758#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler