[bug#39309] [PATCH WIP] gnu: add stack.

[Timothy Sample <samplet@ngyro.com>]

Hello again,

Timothy Sample <samplet@ngyro.com> writes:

> [...]
>
> I’ll take another look with a fresh mind sometime, and see if I can make
> any progress.

I don’t have a solution, but I have a bit more info.  Cabal generates
extremely long argument lists for GCC.  For whatever reason, it repeats
the same flags many times (maybe once for each Haskell dependency).
When building Stack, it passes Gawk as an include path 164 times.  In
fact, there are only a handful of distinct include paths, each passed
164 times.  The linker flags are similar but much worse.

This should be fine since everything is using a response file, right?
Nope.  Like the bug you linked discusses, GCC writes all of its
arguments into an environment variable, the length of which is limited
by “MAX_ARG_STRLEN” (which is 128K).  It would be nice to fix GCC here,
and it’s almost a very small fix, but there is minor complication.  The
normal response file handling in GCC expects “argc” and “argv”
parameters, but the environment variable doesn’t come with an “argc”.
Rather, it has to be parsed (in the same way the shell would do it).
It’s still doable, but a it would be a larger change.  Not to mention
that patching GCC is even less fun than patching GHC.

There was some work to deduplicate the flags that Cabal generates:
<https://github.com/haskell/cabal/pull/5356/>.  This would actually fix
the build, but the call to “hsc2hs” doesn’t do the same deduplication
(see “ppHsc2hs” in “Cabal/Distribution/Simple/PreProcess.hs”).

At this point, it might be worth joining the Nix folks on that issue,
and suggesting a patch to Cabal to call “hsc2hs” with deduplicated
flags.  It will help that the other deduplication code was written by
the same person who filed the bug you linked to earlier.  Once the patch
lands, we can apply it to our Cabal and then Stack will build.  Yay!


-- Tim