jgm / gitit

A wiki using HAppS, pandoc, and git
GNU General Public License v2.0
2.15k stars 226 forks source link

Installation (`stack install` after `git clone`) failure under Windows 10 #651

Open capn-freako opened 4 years ago

capn-freako commented 4 years ago

I'm following the suggested installation instructions, under Windows 10, by entering the following commands at a Git MINGW64 terminal prompt:

and getting this:

{snip}
Cabal                            > [219 of 220] Compiling Distribution.Simple.Doctest
Cabal                            > [220 of 220] Compiling Distribution.Simple
Cabal                            > copy/register
Cabal                            > Installing library in C:\sr\snapshots\67f8afe8\lib\x86_64-windows-ghc-8.6.5\Cabal-2.4.1.0-5rQrtDcYhR2LOcYye7obEr
Cabal                            > Registering library for Cabal-2.4.1.0..

--  While building package sendfile-0.7.11.1 using:
      C:\sr\setup-exe-cache\x86_64-windows\Cabal-simple_Z6RU0evB_2.4.0.1_ghc-8.6.5.exe --builddir=.stack-work\dist\e626a42b build --ghc-options " -fdiagnostics-color=always"
    Process exited with code: ExitFailure 1
Progress 75/157

I tried running the stack install command in a Cygwin command shell, instead, and got:

{snip}
attoparsec          > [20 of 21] Compiling Data.Attoparsec.Char8
attoparsec          > [21 of 21] Compiling Data.Attoparsec
attoparsec          > copy/register
attoparsec          > Installing library in C:\sr\snapshots\67f8afe8\lib\x86_64-windows-ghc-8.6.5\attoparsec-0.13.2.3-GA
4ycFABWuC8tgunM2kJRL
attoparsec          > Registering library for attoparsec-0.13.2.3..

--  While building package sendfile-0.7.11.1 using:
      C:\sr\setup-exe-cache\x86_64-windows\Cabal-simple_Z6RU0evB_2.4.0.1_ghc-8.6.5.exe --builddir=.stack-work\dist\e626a
42b build --ghc-options " -fdiagnostics-color=always"
    Process exited with code: ExitFailure 1
Progress 13/83

Attempting the stack install command from a Windows command prompt yields a similar result.

Scanning all 3 transcripts for errors (They all produce many warnings.) yields:

MINGW64:

cmark-gfm                        > cbits\tasklist.c:17:17: error:
cmark-gfm                        >    |
cmark-gfm                        > 17 |   if (!node || ((int)node->as.opaque != CMARK_TASKLIST_CHECKED && (int)node->as.opaque != CMARK_TASKLIST_NOCHECKED))
cmark-gfm                        >    |                 ^
cmark-gfm                        > cbits\tasklist.c:17:67: error:
cmark-gfm                        >    |
cmark-gfm                        > 17 |   if (!node || ((int)node->as.opaque != CMARK_TASKLIST_CHECKED && (int)node->as.opaque != CMARK_TASKLIST_NOCHECKED))
cmark-gfm                        >    |                                                                   ^

{Omitted 2 more like the above, from the same file.}

sendfile                         > src\Network\Socket\SendFile\Win32.hsc:103:1: error:
sendfile                         >     |
sendfile                         > 103 | foreign import ccall unsafe "io.h _get_osfhandle"
sendfile                         >     | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^...

Cygwin:

(Contains only the last error reported above.)

CMD:

Same as above, but with additional diagnostic information:

sendfile            > src\Network\Socket\SendFile\Win32.hsc:103:1: error:
sendfile            >     * Unacceptable result type in foreign declaration:
sendfile            >         `IntPtr' cannot be marshalled in a foreign call
sendfile            >           because its data constructor is not in scope
sendfile            >           Possible fix: import the data constructor to bring it into scope
sendfile            >     * When checking declaration:
sendfile            >         foreign import ccall unsafe "io.h _get_osfhandle" c_get_osfhandle
sendfile            >           :: Fd -> IO IntPtr
sendfile            >     |
sendfile            > 103 | foreign import ccall unsafe "io.h _get_osfhandle"
sendfile            >     | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^...

Oh, I just noticed this, at the very start of my console output:

WARNING: Ignoring sendfile's bounds on Win32 (>=2.2.0.0 && <2.3); using Win32-2.6.1.0.
Reason: allow-newer enabled.
capn-freako commented 4 years ago

When attempting the alternative Haskell Platform based installation, from either the Git MINGW64, or Cygwin, I'm getting this strange error:

Failed to install network-2.8.0.1
Build log ( C:\Users\capnf\AppData\Roaming\cabal\logs\ghc-8.6.5\network-2.8.0.1-41igyNI75uzGO9xrEXCykL.log ):
Configuring network-2.8.0.1...
cabal.exe: The package has a './configure' script. If you are on Windows, This
requires a Unix compatibility toolchain such as MinGW+MSYS or Cygwin. If you
are not on Windows, ensure that an 'sh' command is discoverable in your path.

I have the following line in my cabal config file:

extra-prog-path: C:\Program Files\Haskell Platform\8.6.5\msys\usr\bin,
                 C:\Users\capnf\AppData\Roaming\cabal\bin

And there is a sh.exe file in the C:\Program Files\Haskell Platform\8.6.5\msys\usr\bin directory.

jgm commented 4 years ago

Hm, I'm not sure what to suggest. I've never built gitit on Windows. These are build failures for dependent libraries, not pandoc itself. Probably there's something wrong with your build setup, but since I don't develop on Windows, I couldn't tell you what.

capn-freako commented 4 years ago

Okay, I was able to get the Haskell Platform approach to work, by doing the following:

jgm commented 2 years ago

I just encountered this same error after adding Windows to the CI: https://github.com/jgm/gitit/runs/4490058242?check_suite_focus=true

jgm commented 2 years ago

We now work around this by setting the portable flag on sendfile, which may affect performance.