You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
GHC has a quirk where to work around the fact that our input file to GCC is in another folder, we add the original input directory to the include search path. This causes a problem since new include paths override system ones. It doesn't however do this for all modes.
For some reasons I have yet to figure out, compiling with cabal works, but not one shot compilation.
Anyway, long story short, when building GHC, the presence of this file names "windows.h" is causing GCC to loop on the includes before eventually terminating. While I'm looking into this it would be really helpful if you could rename this file to something else. That should unblock certain build failures.
GHC has a quirk where to work around the fact that our input file to GCC is in another folder, we add the original input directory to the include search path. This causes a problem since new include paths override system ones. It doesn't however do this for all modes.
For some reasons I have yet to figure out, compiling with cabal works, but not one shot compilation.
Anyway, long story short, when building GHC, the presence of this file names "windows.h" is causing GCC to loop on the includes before eventually terminating. While I'm looking into this it would be really helpful if you could rename this file to something else. That should unblock certain build failures.
See https://ghc.haskell.org/trac/ghc/ticket/14312
The text was updated successfully, but these errors were encountered: