MSYS paths incorrectly recognized as relative on Windows

[mtolly]

On Windows, I'd like to use Unix-style paths, which reference directories inside the Stack-installed MSYS2 environment, for library and include directories. My tests below were on Windows 7 64-bit with 32-bit Stack.

Steps to reproduce

Clone https://github.com/mtolly/stack-msys. The important parts are, in stack.yaml,

extra-lib-dirs:
- /mingw32/lib
extra-include-dirs:
- /mingw32/include

And in stack-msys.cabal:

build-depends:        base >= 4.7 && < 5, base64-bytestring

The base64-bytestring is not important -- it can be any other package, but for whatever reason the problem only shows up when you have at least one dependency that needs to be compiled beforehand. (So, if you don't see the problem because base64-bytestring is already compiled, try either changing it to some other package, or deleting the precompiled one from your %AppData%/stack/snapshots folder.)

Expected:

The directories, by virtue of starting with /, are recognized as Unix absolute paths and so are located relative to the Stack-local MSYS2 installation; for example mine would be C:\Users\Mike\AppData\Local\Programs\stack\i386-windows\msys2-20150512\<dir starts here>.

The directory may not exist; this should be ignored with just a warning, not a fatal error. Specifically my end goal here is to have this in my stack.yaml:

extra-lib-dirs:
- /mingw32/lib # windows
- /usr/local/lib # mac homebrew
extra-include-dirs:
- /mingw32/include # windows
- /usr/local/include # mac homebrew

Actual:

This is from, inside cmd.exe, running stack exec bash, so apologies for the hard wrapping.

Mike@Mike-PC  ~/stack-msys
$ stack --version
Version 1.0.4, Git revision cf18703b1392a96a5a4896a560309e501af63260 (3220 commi
ts) i386

Mike@Mike-PC  ~/stack-msys
$ stack build
base64-bytestring-1.0.0.1: configure
base64-bytestring-1.0.0.1: build

--  While building package base64-bytestring-1.0.0.1 using:
      C:\Users\Mike\AppData\Roaming\stack\setup-exe-cache\i386-windows\setup-Sim
ple-Cabal-1.22.5.0-ghc-7.10.3.exe --builddir=.stack-work\dist\95439361 build --g
hc-options " -ddump-hi -ddump-to-file"
    Process exited with code: ExitFailure 1
    Logs have been written to: C:\Users\Mike\AppData\Local\Programs\stack\i386-w
indows\msys2-20150512\home\Mike\stack-msys\.stack-work\logs\base64-bytestring-1.
0.0.1.log

    Configuring base64-bytestring-1.0.0.1...
    Warning: 'extra-lib-dirs: /mingw32/lib' directory does not exist.
    Warning: 'include-dirs: /mingw32/include' directory does not exist.
    Building base64-bytestring-1.0.0.1...
    Preprocessing library base64-bytestring-1.0.0.1...
    [1 of 5] Compiling Data.ByteString.Base64.Internal ( Data\ByteString\Base64\
Internal.hs, .stack-work\dist\95439361\build\Data\ByteString\Base64\Internal.o )

    [2 of 5] Compiling Data.ByteString.Base64.URL ( Data\ByteString\Base64\URL.h
s, .stack-work\dist\95439361\build\Data\ByteString\Base64\URL.o )
    [3 of 5] Compiling Data.ByteString.Base64.URL.Lazy ( Data\ByteString\Base64\
URL\Lazy.hs, .stack-work\dist\95439361\build\Data\ByteString\Base64\URL\Lazy.o )

    [4 of 5] Compiling Data.ByteString.Base64 ( Data\ByteString\Base64.hs, .stac
k-work\dist\95439361\build\Data\ByteString\Base64.o )
    [5 of 5] Compiling Data.ByteString.Base64.Lazy ( Data\ByteString\Base64\Lazy
.hs, .stack-work\dist\95439361\build\Data\ByteString\Base64\Lazy.o )
    In-place registering base64-bytestring-1.0.0.1...
    setup-Simple-Cabal-1.22.5.0-ghc-7.10.3.exe:
    'C:\Users\Mike\AppData\Local\Programs\stack\i386-windows\ghc-7.10.3\bin\ghc-
pkg.exe'
    exited with an error:
    base64-bytestring-1.0.0.1: Warning: haddock-interfaces:
    C:\Users\Mike\AppData\Local\Temp\stack3800\base64-bytestring-1.0.0.1\.stack-
work\dist\95439361\doc\html\base64-bytestring\base64-bytestring.haddock
    doesn't exist or isn't a file
    base64-bytestring-1.0.0.1: Warning: haddock-html:
    C:\Users\Mike\AppData\Local\Temp\stack3800\base64-bytestring-1.0.0.1\.stack-
work\dist\95439361\doc\html\base64-bytestring
    doesn't exist or isn't a directory
    base64-bytestring-1.0.0.1: library-dirs: /mingw32/lib is a relative path whi
ch
    makes no sense (as there is nothing for it to be relative to). You can make
    paths relative to the package database itself by using ${pkgroot}. (use
    --force to override)
    base64-bytestring-1.0.0.1: include-dirs: /mingw32/include is a relative path

    which makes no sense (as there is nothing for it to be relative to). You can

    make paths relative to the package database itself by using ${pkgroot}. (use

    --force to override)
Progress: 1/2
Mike@Mike-PC  ~/stack-msys
$

Note that the two warnings about the dirs not existing are false, since they do exist.

Here is the verbose output.

This problem does not occur if, instead of specifying the dirs in stack.yaml, I pass them on the command line with stack build --extra-lib-dirs=/mingw32/lib --extra-include-dirs=/mingw32/include. I suspect this is just because the MSYS shell is converting them to Windows paths before Stack even sees them, but it's possible Stack could be treating them differently as well.

[mgsloan]

Yeah, seems like a good thing to fix. I suppose it'd be done by munging the paths when invoking Cabal configure.

PRs appreciated! :)

[unhammer]

Are there any good workarounds in the meanwhile? Other than passing --extra-include-dirs/--extra-lib-dirs on each invocation :-/

[mtolly]

I don't know if this matches what you're doing @unhammer but I eventually discovered that the mingw lib/install dirs (that stuff gets put into if you run for example stack exec -- pacman -Sy mingw-w64-x86_64-libfoo) are already included by stack, but only if you run it from outside msys's bash. So just from the cmd.exe prompt, if you run stack build it will see those libraries + headers correctly, but not if you run stack exec bash and then stack build inside that, for some reason.

Also see #2547 in case that might apply to what you're doing since it mentions the extra steps I had to figure out to make this setup work.

[unhammer]

In our case, the problem is kind of the other way around. I have extra-include-dirs: [/usr/include] extra-lib-dirs: [/usr/lib/x86_64-linux-gnu/odbc/] in the stack.yaml for compiling on Linux. But on Windows we've been using plain cabal because of this issue, so we just have extra-lib-dirs: lib in the .cabal (some dll's bundled with the source).

[mpilgrem]

I am not certain this is a manifestation of the same problem, but it also seems to involve /mingw64/lib being understood as a relative path during a stack build on Windows. In trying to build brotli-0.0.0.0 on Windows 11, I had to replace pkgconfig-depends: in its .cabal file with an equivalent extra-libraries: (see haskell-hvr/brotli#3 and #5679 (comment)), in order to avoid this error:

brotli-0.0.0.0: library-dirs: /mingw64/lib is a relative path which makes no
sense (as there is nothing for it to be relative to). You can make paths
relative to the package database itself by using ${pkgroot}. (use --force to
override)
brotli-0.0.0.0: dynamic-library-dirs: /mingw64/lib is a relative path which
makes no sense (as there is nothing for it to be relative to). You can make
paths relative to the package database itself by using ${pkgroot}. (use
--force to override)

--  While building package brotli-0.0.0.0 (scroll up to its section to see the error) using:
      C:\sr\setup-exe-cache\x86_64-windows\Cabal-simple_Z6RU0evB_3.4.1.0_ghc-9.0.2.exe --builddir=.stack-work\dist\d53b6a14 register
    Process exited with code: ExitFailure 1