#14312: Head does not build on Windows with the default make config. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.2.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by AndreasK: Old description:

Cloning head and just running:

{{{ ./boot ./configure --enable-tarballs-autodownload make }}}

Fails since at least two weeks and still does as of a4ee28978acbcf68da9dfb6f198cb6e1ff38ccca

The main issue is the directory library fails to build.

Creating a build.mk file and setting the Flavour to quick GHC does build as expected.

What triggers the failure seems to be the windows.h file created by the directory library which in some way includes itself in a loop until the preprocessor/c-compiler gives up.

Renaming the file locally seems to be a viable workaround.

New description: Cloning head and just running: {{{ ./boot ./configure --enable-tarballs-autodownload make }}} Fails since at least two weeks and still does as of a4ee28978acbcf68da9dfb6f198cb6e1ff38ccca The main issue is the directory library fails to build. Creating a build.mk file and setting the Flavour to quick GHC does build as expected. What triggers the failure seems to be the windows.h file created by the directory library which in some way includes itself in a loop until the preprocessor/c-compiler gives up. Renaming the file locally seems to be a viable workaround. I used https://github.com/Mistuke/GhcDevelChoco to set up a build environment and it happens on both my machines so doesn't seem to be a fluke. -- -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14312#comment:1> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

#14312: Head does not build on Windows with the default make config. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: upstream Priority: normal | Milestone: Component: Build System | Version: 8.2.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * status: new => upstream Comment: The first offending command is {{{ "inplace/bin/ghc-stage1.exe" -hisuf p_hi -osuf p_o -hcsuf p_hc -static -prof -eventlog -H32m -O -Wall -this-unit-id directory-1.3.1.2 -hide-all-packages -i -ilibraries/directory/. -ilibraries/directory/dist- install/build -Ilibraries/directory/dist-install/build -ilibraries/directory/dist-install/build/./autogen -Ilibraries/directory /dist-install/build/./autogen -Ilibraries/directory/. -optP-include -optPlibraries/directory/dist-install/build/./autogen/cabal_macros.h -package-id base-4.11.0.0 -package-id time-1.8.0.2 -package-id filepath-1.4.1.2 -package-id Win32-2.5.4.1 -Wall -XHaskell2010 -O2 -no- user-package-db -rtsopts -Wno-unused-imports -Wno-deprecated-flags -Wnoncanonical-monad-instances -odir libraries/directory/dist- install/build -hidir libraries/directory/dist-install/build -stubdir libraries/directory/dist-install/build -split-objs -c libraries/directory/./System/Directory/Internal/Config.hs -o libraries/directory/dist- install/build/System/Directory/Internal/Config.p_o }}} which is trying to compile `libraries/directory/./System/Directory/Internal/Config.hs` which is also the folder that also contains the `windows.h` dummy implementation for `directory`. This corresponds to the following `gcc` command {{{ "E:\ghc-dev\msys64\home\Tamar\ghc\inplace\lib/../mingw/bin/gcc.exe" "-fno- stack-protector" "-DTABLES_NEXT_TO_CODE" "-DTRACING" "-DPROFILING" "-x" "c" "E:\ghc-dev\msys64\tmp\ghc5148_0\ghc_4.c" "-o" "E:\ghc- dev\msys64\tmp\ghc5148_0\ghc_5.s" "-no-pie" "-Wimplicit" "-S" "-O2" "-include" "E:/ghc-dev/msys64/home/Tamar/ghc/includes\ghcversion.h" "-Ilibraries\directory\System\Directory\Internal" "-Ilibraries/directory /dist-install/build" "-Ilibraries/directory/dist-install/build" "-Ilibraries/directory/dist-install/build/./autogen" "-Ilibraries/directory/." "-IE:\ghc- dev\msys64\home\Tamar\ghc\libraries\time\lib/include" "-IE:\ghc- dev\msys64\home\Tamar\ghc\libraries\Win32\include" "-IE:\ghc- dev\msys64\home\Tamar\ghc\libraries\bytestring\include" "-IE:\ghc- dev\msys64\home\Tamar\ghc\libraries\base\include" "-IE:\ghc- dev\msys64\home\Tamar\ghc\libraries\integer-gmp\include" "-IE:/ghc- dev/msys64/home/Tamar/ghc/rts/dist/build" "-IE:/ghc- dev/msys64/home/Tamar/ghc/includes" "-IE:/ghc- dev/msys64/home/Tamar/ghc/includes/dist-derivedconstants/header" }}} The problem is the `"-Ilibraries\directory\System\Directory\Internal"` that GCC adds, this line comes from `let cmdline_include_paths = includePaths dflags` in `runPhase (RealPhase cc_phase) input_fn dflags`. This particularly entry comes from a modification we do to the include paths: `dflags1 { includePaths = current_dir : old_paths ...` So we always add the current directory to the include paths. Normally this wouldn't be an issue as system include paths should take precedence over user ones. The problem however is that Windows doesn't have such a concept, and I suspect the `mingw` compilers just append extra `-I`. This can be confirmed by the output of standard search directories for this call {{{ GNU C11 (Rev2, Built by MSYS2 project) version 6.3.0 (x86_64-w64-mingw32) compiled by GNU C version 6.3.0, GMP version 6.1.2, MPFR version 3.1.5-p2, MPC version 1.0.3, isl version 0.15 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 ignoring duplicate directory "E:/ghc- dev/msys64/home/Tamar/ghc/inplace/mingw/bin/../lib/gcc/x86_64-w64-mingw32/6.3.0/include" ignoring duplicate directory "E:/ghc- dev/msys64/home/Tamar/ghc/inplace/mingw/bin/../lib/gcc/x86_64-w64-mingw32/6.3.0 /include-fixed" ignoring duplicate directory "E:/ghc- dev/msys64/home/Tamar/ghc/inplace/mingw/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/6.3.0/include" ignoring nonexistent directory "C:/building/msys64/mingw64/include" ignoring nonexistent directory "/mingw64/include" ignoring duplicate directory "E:/ghc- dev/msys64/home/Tamar/ghc/inplace/mingw/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/6.3.0 /include-fixed" ignoring duplicate directory "E:/ghc- dev/msys64/home/Tamar/ghc/inplace/mingw/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/6.3.0/../../../../x86_64-w64-mingw32/include" ignoring nonexistent directory "C:/building/msys64/mingw64/x86_64-w64-mingw32/include" ignoring duplicate directory "libraries/directory/dist-install/build" #include "..." search starts here: #include <...> search starts here: libraries\\directory\\System\\Directory\\Internal libraries/directory/dist-install/build libraries/directory/dist-install/build/./autogen libraries/directory/. E:\\ghc-dev\\msys64\\home\\Tamar\\ghc\\libraries\\time\\lib/include E:\\ghc-dev\\msys64\\home\\Tamar\\ghc\\libraries\\Win32\\include E:\\ghc-dev\\msys64\\home\\Tamar\\ghc\\libraries\\bytestring\\include E:\\ghc-dev\\msys64\\home\\Tamar\\ghc\\libraries\\base\\include E:\\ghc-dev\\msys64\\home\\Tamar\\ghc\\libraries\\integer-gmp\\include E:/ghc-dev/msys64/home/Tamar/ghc/rts/dist/build E:/ghc-dev/msys64/home/Tamar/ghc/includes E:/ghc-dev/msys64/home/Tamar/ghc/includes/dist-derivedconstants/header E://ghc- dev//msys64//home//Tamar//ghc//inplace//mingw//bin/../lib/gcc/x86_64-w64-mingw32/6.3.0/include E://ghc- dev//msys64//home//Tamar//ghc//inplace//mingw//bin/../lib/gcc/x86_64-w64-mingw32/6.3.0 /include-fixed E:/ghc- dev/msys64/home/Tamar/ghc/inplace/mingw/bin/../lib/gcc/x86_64-w64-mingw32/6.3.0/../../../../include E:/ghc- dev/msys64/home/Tamar/ghc/inplace/mingw/bin/../lib/gcc/x86_64-w64-mingw32/6.3.0/../../../../x86_64-w64-mingw32/include End of search list. GNU C11 (Rev2, Built by MSYS2 project) version 6.3.0 (x86_64-w64-mingw32) compiled by GNU C version 6.3.0, GMP version 6.1.2, MPFR version 3.1.5-p2, MPC version 1.0.3, isl version 0.15 }}} So the problem seems to be an upstream one. I'm not sure what's the best way to solve this. Ideally the mingw-w64 compilers should recognize their own core include directories as system includes. For now, `directory` can work around this issue by renaming this `windows.h` file. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14312#comment:3> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

#14312: Head does not build on Windows with the default make config. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: upstream Priority: normal | Milestone: Component: Build System | Version: 8.2.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): Actually the GCC manual states: {{{ The most commonly-used option is -Idir, which causes dir to be searched after the current directory (for the quote form of the directive) and ahead of the standard system directories. You can specify multiple -I options on the command line, in which case the directories are searched in left-to-right order. }}} Which means `-I` override system include directories. GCC is doing exactly what It was told to. SO dunno what the correct fix here is. short term, directory should just rename this file. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14312#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

#14312: Head does not build on Windows with the default make config. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: upstream Priority: normal | Milestone: Component: Build System | Version: 8.2.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): @Rufflewind Yes I was going to give `-iquote` a try, but have to first confirm why we do this. This won't fix GHCs that have already been released though of course. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14312#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

#14312: Head does not build on Windows with the default make config. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Build System | Version: 8.2.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4080 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): OK, this is a problem, the real issue here if `capi`. In a foreign import such as `foreign import capi unsafe "HsBase.h tcsetattr"` the header can be a local or a system include. Which leaves is how to generate the includes. We'd need to use quoted paths to get local headers in the same folder, but then we won't be able to use system headers, however I don't see a way around it without a backwards incompatible change... @bgamari, what do you think. Is the cost worth the change here? Keep in mind this isn't Windows specific. You should get the same error on any system. Directory has been updated so we can just update the submodule to fix it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14312#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

#14312: Head does not build on Windows with the default make config. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Build System | Version: 8.3 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4080 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): Well, the proposal is more to not add the current file's folder implicitly to the include list. Make it an implicit choice. Looking at the options, maybe `-isystem` or `-idirafter` would work. Will have to test. But if not, think we should drop adding the path. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14312#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

#14312: Head does not build on Windows with the default make config. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Build System | Version: 8.3 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4080 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Rufflewind): In ordinary C code I would always expect `#include "..."` to search the current directory of the file (as apparent to the user), whereas `#include <...>` should not do that unless explicitly asked for. I think Haskell should aim to retain similar behavior. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14312#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

#14312: Head does not build on Windows with the default make config. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Build System | Version: 8.3 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4080 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): This seems to have been introduced by {{{ commit 06d46b1e4507e09eb2a7a04998a92610c8dc6277 Author: Edward Z. Yang <ezyang@cs.stanford.edu> Date: Fri Jul 24 15:13:49 2015 -0700 Unify hsig and hs-boot; add preliminary "hs-boot" merging. This patch drops the file level distinction between hs-boot and hsig; we figure out which one we are compiling based on whether or not there is a corresponding hs file lying around. To make the "import A" syntax continue to work for bare hs-boot files, we also introduce hs-boot merging, which takes an A.hi-boot and converts it to an A.hi when there is no A.hs file in scope. This will be generalized in Backpack to merge multiple A.hi files together; which means we can jettison the "load multiple interface files" functionality. This works automatically for --make, but for one-shot compilation we need a new mode: ghc --merge-requirements A will generate an A.hi/A.o from a local A.hi-boot file; Backpack will extend this mechanism further. Has Haddock submodule update to deal with change in msHsFilePath behavior. - This commit drops support for the hsig extension. Can we support it? It's annoying because the finder code is written with the assumption that where there's an hs-boot file, there's always an hs file too. To support hsig, you'd have to probe two locations. Easier to just not support it. - #10333 affects us, modifying an hs-boot still doesn't trigger recomp. - See compiler/main/Finder.hs: this diff is very skeevy, but it seems to work. - This code cunningly doesn't drop hs-boot files from the "drop hs-boot files" module graph, if they don't have a corresponding hs file. I have no idea if this actually is useful. Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: validate Reviewers: simonpj, austin, bgamari, spinda Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1098 }}} with the comment {{{ + -- We add the directory in which the .hs files resides) to the import + -- path. This is needed when we try to compile the .hc file later, if it + -- imports a _stub.h file that we created here. }}} So it seems unrelated to `capi` but the `capi` test require this to pass. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14312#comment:15> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

#14312: Head does not build on Windows with the default make config. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: patch Priority: high | Milestone: 8.6.1 Component: Build System | Version: 8.3 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4080 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.4.1 => 8.6.1 Comment: Ahh, judging from the release notes the answer is clearly no. Re- milestoning. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14312#comment:17> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

#14312: Head does not build on Windows with the default make config. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: patch Priority: high | Milestone: 8.6.1 Component: Build System | Version: 8.3 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4080 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari <ben@…>): In [changeset:"eb2daa2b6a83412382aa0fcda598f8b3d40fde2c/ghc" eb2daa2b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="eb2daa2b6a83412382aa0fcda598f8b3d40fde2c" Change how includes for input file directory works GHC Used to only allow for one include mode, namely `-I`. The problem with `-I` includes is that it supercedes all other includes, including the system include paths. This is not a problem for paths requested by the user, but it is a problem for the ones we implicitly derive and add. In particular we add the source directory of the input file to the include path. This is problematic because it causes any file with the name of a system include, to inadvertently loop as the wrong file gets included. Since this is an implicitly include, and as far as I can tell, only done so local includes are found (as the sources given to GCC reside in a temp folder) then switch from `-I` to `-iquote`. This requires a submodule update for haddock Test Plan: ./validate Reviewers: austin, bgamari, hvr Reviewed By: bgamari Subscribers: carter, rwbarton, thomie GHC Trac Issues: #14312 Differential Revision: https://phabricator.haskell.org/D4080 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14312#comment:19> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler