Opened 3 years ago

Closed 3 years ago

#13166 closed bug (invalid)

Warning: Can't find file "C:\...\lib/include\ghcversion.h" in directories

Reported by: domenkozar Owned by:
Priority: normal Milestone:
Component: Compiler Version: 8.0.2
Keywords: Cc: domen@…
Operating System: Windows Architecture: Unknown/Multiple
Type of failure: Incorrect error/warning at compile-time Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:

Description

I'm not exactly sure yet where this is coming from, but I'd like to report an warning on Windows during preprocessing phase:

[00:03:39] Preprocessing library cardano-sl-0.1.0.0...
[00:03:39] Warning: Can't find file "C:\Users\appveyor\AppData\Local\Programs\stack\x86_64-windows\ghc-8.0.1\lib/include\ghcversion.h" in directories
[00:03:39] 	src/Pos
[00:03:39] 	.
[00:03:39] 	.stack-work\dist\b7fec021\build
[00:03:39] 	.stack-work\dist\b7fec021\build
[00:03:39] 	.stack-work\dist\b7fec021\build\autogen
[00:03:39] 	.stack-work\dist\b7fec021\build
[00:03:39] 	C:\OpenSSL-Win64\include
[00:03:39] 	C:\Users\appveyor\AppData\Local\Programs\stack\x86_64-windows\msys2-20150512\mingw64\include
[00:03:39] 	C:\projects\pos-haskell-prototype\rocksdb\include
[00:03:39] 	C:\OpenSSL-Win64\include
[00:03:39] 	C:\Users\appveyor\AppData\Local\Programs\stack\x86_64-windows\msys2-20150512\mingw64\include
[00:03:39] 	C:\projects\pos-haskell-prototype\rocksdb\include
[00:03:39] 	C:\sr\snapshots\a78c6a89\lib\x86_64-windows-ghc-8.0.1\vector-algorithms-0.7.0.1-8R8UpWgvBC926XMxBjYPpx\include
[00:03:39] 	C:\sr\snapshots\a78c6a89\lib\x86_64-windows-ghc-8.0.1\zlib-0.6.1.2-4CWLN1T27kOJhNvXgy46ZV\include
[00:03:39] 	C:\Users\appveyor\AppData\Local\Programs\stack\x86_64-windows\ghc-8.0.1\lib\process-1.4.2.0\include
[00:03:39] 	C:\sr\snapshots\a78c6a89\lib\x86_64-windows-ghc-8.0.1\vector-0.11.0.0-BEDZb5o2QOhGbIm6ky7rl6\include
[00:03:39] 	C:\sr\snapshots\a78c6a89\lib\x86_64-windows-ghc-8.0.1\old-time-1.1.0.3-IcvdkJUsE9M8t3io8peAEp\include
[00:03:39] 	C:\Users\appveyor\AppData\Local\Programs\stack\x86_64-windows\ghc-8.0.1\lib\directory-1.2.6.2\include
[00:03:39] 	C:\sr\snapshots\a78c6a89\lib\x86_64-windows-ghc-8.0.1\primitive-0.6.1.0-Ip44DqhfCp21tTUYbecwa\include
[00:03:39] 	C:\Users\appveyor\AppData\Local\Programs\stack\x86_64-windows\ghc-8.0.1\lib\time-1.6.0.1\include
[00:03:39] 	C:\Users\appveyor\AppData\Local\Programs\stack\x86_64-windows\ghc-8.0.1\lib\Win32-2.3.1.1\include
[00:03:39] 	C:\sr\snapshots\a78c6a89\lib\x86_64-windows-ghc-8.0.1\network-2.6.3.1-nK9qnsiJR03CWuPIGMmX\include
[00:03:39] 	C:\Users\appveyor\AppData\Local\Programs\stack\x86_64-windows\ghc-8.0.1\lib\bytestring-0.10.8.1\include
[00:03:39] 	C:\Users\appveyor\AppData\Local\Programs\stack\x86_64-windows\ghc-8.0.1\lib\base-4.9.0.0\include
[00:03:39] 	C:\Users\appveyor\AppData\Local\Programs\stack\x86_64-windows\ghc-8.0.1\lib\integer-gmp-1.0.0.1\include
[00:03:39] 	C:\Users\appveyor\AppData\Local\Programs\stack\x86_64-windows\ghc-8.0.1\lib/include
[00:03:39]   Asked for by: src/Pos/CLI.hs  at line 2 col 1

It appears to trigger for each module using cpphs. The file is present, so I suspect the problem is in unix path character in C:\Users\appveyor\AppData\Local\Programs\stack\x86_64-windows\ghc-8.0.1\lib/include\ghcversion.h.

Using verbose mode we can observe that's the case:

"cpphs" "-DWITH_WEB" "-DWITH_WALLET" "-include" ".stack-work\dist\ca59d0ab\build\autogen\cabal_macros.h" "--cpp" "-I" ".stack-work\dist\ca59d0ab\build" "-I" ".stack-work\dist\ca59d0ab\build" "-I" ".stack-work\dist\ca59d0ab\build\autogen" "-I" ".stack-work\dist\ca59d0ab\build" "-I" "C:\OpenSSL-Win64\include" "-I" "C:\Users\Administrator\AppData\Local\Programs\stack\x86_64-windows\msys2-20150512\mingw64\include" "-I" "C:\rocksdb\include" "-I" "C:\OpenSSL-Win64\include" "-I" "C:\Users\Administrator\AppData\Local\Programs\stack\x86_64-windows\msys2-20150512\mingw64\include" "-I" "C:\rocksdb\includ
e" "-I" "C:\sr\snapshots\b3566c00\lib\x86_64-windows-ghc-8.0.2\vector-algorithms-0.7.0.1-C2u1KYklHg84I6SQQVEAin\include" "-I" "C:\sr\snapshots\bb34f894\lib\x86_64-windows-ghc-8.0.2\zlib-0.6.1.2-7negTfm2ujt1gW4wr40MUp\include" "-I" "C:\sr\snapshots\bb34f894\lib\x86_64-windows-ghc-8.0.2\process-1.4.2.0-KoK49SuYVPk1TQ4YVt6ZK5\include" "-I" "C:\sr\snapshots\bb34f894\lib\x86_64-windows-ghc-8.0.2\vector-0.11.0.0-LMwQhhnXj8U3T5Bm1JFxG\include" "-I" "C:\sr\snapshots\bb34f894\lib\x86_64-windows-ghc-8.0.2\old-time-1.1.0.3-KWRsMSdY26c2L27Y9n9cyq\include" "-I" "C:\sr\snapshots\bb34f894\lib\x86_64-windows-
ghc-8.0.2\directory-1.2.6.2-qiZgXsB5o98ZsOYUWltfF\include" "-I" "C:\sr\snapshots\bb34f894\lib\x86_64-windows-ghc-8.0.2\primitive-0.6.1.0-6AbSTw9JXz141LE5p6LGH\include" "-I" "C:\Users\Administrator\AppData\Local\Programs\stack\x86_64-windows\ghc-8.0.2\lib\time-1.6.0.1\include" "-I" "C:\Users\Administrator\AppData\Local\Programs\stack\x86_64-windows\ghc-8.0.2\lib\Win32-2.3.1.1\include" "-I" "C:\sr\snapshots\bb34f894\lib\x86_64-windows-ghc-8.0.2\network-2.6.3.1-AwRxOQvT8JM9e8zDFK7aCI\include" "-I" "C:\Users\Administrator\AppData\Local\Programs\stack\x86_64-windows\ghc-8.0.2\lib\bytestring-0.10.8.
1\include" "-I" "C:\Users\Administrator\AppData\Local\Programs\stack\x86_64-windows\ghc-8.0.2\lib\base-4.9.1.0\include" "-I" "C:\Users\Administrator\AppData\Local\Programs\stack\x86_64-windows\ghc-8.0.2\lib\integer-gmp-1.0.0.1\include" "-I" "C:\Users\Administrator\AppData\Local\Programs\stack\x86_64-windows\ghc-8.0.2\lib/include" "-D__GLASGOW_HASKELL__=800" "-include" "C:\Users\Administrator\AppData\Local\Programs\stack\x86_64-windows\ghc-8.0.2\lib/include\ghcversion.h" "-Dmingw32_BUILD_OS=1" "-Dx86_64_BUILD_ARCH=1" "-Dmingw32_HOST_OS=1" "-Dx86_64_HOST_ARCH=1" "-D__GLASGOW_HASKELL_TH__=1" "-D_
_SSE__=1" "-D__SSE2__=1" "-includeC:\Users\ADMINI~1\AppData\Local\Temp\2\ghc2384_0\ghc_18.h" "-x" "assembler-with-cpp" "src\Pos\Binary\Crypto.hs" "-o" "C:\Users\ADMINI~1\AppData\Local\Temp\2\ghc2384_0\ghc_17.hscpp"

I highly suspect https://github.com/ghc/ghc/blob/master/utils/ghc-pkg/Main.hs#L1956 since it does some unclear path mungling, probably leaving undosified suffix. Note that those functions were copied from compiler/main/SysTools.hs which changed significantly.

Change History (9)

comment:1 Changed 3 years ago by mpickering

Status: newinfoneeded

How can we reproduce this?

comment:2 Changed 3 years ago by domenkozar

Any package using cpphs on Windows should do. For example:

git clone https://github.com/asr/pdfname.git
cd pdfname
stack init
stack build

comment:3 Changed 3 years ago by Phyx-

Priority: lownormal
Status: infoneededupstream

Windows has no problem with forward slashes in paths. See the note on https://msdn.microsoft.com/en-gb/library/windows/desktop/aa365247(v=vs.85).aspx

My guess of what's going on is the cpphs is incorrectly handling fully qualified paths. It must be combining the search directories and file, and incorrectly handling the . case.

You should report this to cpphs https://github.com/malcolmwallace/cpphs/issues

The error is there and not GHC.

Could you link back to here as well?

comment:4 Changed 3 years ago by domenkozar

Are you absolutely sure that's correct?

Windows can handle forward slashes, but they don't count as file/folder separators.

You can observe in my ticket report how GHC calls cpphs with incorrect path to the file, but I don't see how cpphs is responsible how it's called:

 "-include" "C:\Users\Administrator\AppData\Local\Programs\stack\x86_64-windows\ghc-8.0.2\lib/include\ghcversion.h" 

comment:5 in reply to:  4 Changed 3 years ago by awson

Replying to domenkozar:

Windows can handle forward slashes, but they don't count as file/folder separators.

Wrong.

comment:6 Changed 3 years ago by Phyx-

The path isn't incorrect, It's a perfectly valid Windows path. DOS path separator character \ isn't required by the API at all. The behavior you're alluding to is that of DOS or command.com, not NT.

The page I pointed you to explicitly says:

Note  File I/O functions in the Windows API convert "/" to "\" as part
of converting the name to an NT-style name, except when using the "\\?\"
prefix as detailed in the following sections.

You can see an overview here https://en.wikipedia.org/wiki/Path_%28computing%29

or you can just experiment yourself:

C:\Users\tamar\Desktop>mkdir foo
C:\Users\tamar\Desktop>echo "hello world" > foo/test.txt
C:\Users\tamar\Desktop>dir foo
 Volume in drive C is Windows
 Volume Serial Number is ...

 Directory of C:\Users\tamar\Desktop\foo

01/02/2017  10:17    <DIR>          .
01/02/2017  10:17    <DIR>          ..
01/02/2017  10:17                16 test.txt
               1 File(s)             16 bytes
               2 Dir(s)  45,293,834,240 bytes free

The error is being generated by cpphs and we've given it a valid path.

comment:8 Changed 3 years ago by Phyx-

Thanks!

comment:9 Changed 3 years ago by Phyx-

Resolution: invalid
Status: upstreamclosed

I actually have just realised that we don't bundle or ship cpphs at all. So this is unrelated to the toolchain.

It's purely a user package issue as such I'll close this issue but will continue to monitor upstream.

Note: See TracTickets for help on using tickets.