Unix-style /mingw64/... paths not understood

[jasagredo]

In MinGW, pkgconf (at least 2.1.0) offers /mingw64/include as an include-dirs. This is rejected by saying the following:

data-dir: C:\Users\Javier\aa\.
hs-libraries: HSaa-0.1.0.0-inplace
extra-libraries: tcl86 tclstub86 tre intl
extra-libraries-static: tcl86 tclstub86 tre intl z
include-dirs:
C:/msys64/mingw64/include /mingw64/include /mingw64/include
...
'C:\ghcup\bin\ghc-pkg.exe' exited with an error:
aa-0.1.0.0: Warning: haddock-interfaces: C:\Users\Javier\aa\dist-newstyle\build\x86_64-windows\ghc-9.6.3\aa-0.1.0.0\doc\html\aa\aa.haddock doesn't exist or isn't a file
aa-0.1.0.0: Warning: haddock-html: C:\Users\Javier\aa\dist-newstyle\build\x86_64-windows\ghc-9.6.3\aa-0.1.0.0\doc\html\aa doesn't exist or isn't a directory
aa-0.1.0.0: include-dirs: /mingw64/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)
aa-0.1.0.0: include-dirs: /mingw64/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)
CallStack (from HasCallStack):
  dieWithException, called at src\Distribution\Simple\Program\Run.hs:160:7 in Cabal-3.11.0.0-inplace:Distribution.Simple.Program.Run

CallStack (from HasCallStack):
  dieWithException, called at src\Distribution\Client\ProjectOrchestration.hs:1226:21 in cabal-install-3.11.0.0-inplace:Distribution.Client.ProjectOrchestration

I'm unsure whether this is a Cabal bug or a GHC (or for that matter ghc-pkg) bug, but perhaps Cabal can fix it? There should be some way of normalizing that path. Note that the path exists:

❯ ls /mingw64/include
_bsd_types.h            d3d11_3.idl                     flif_enc.h                          math.h                        ole2ver.h                        stddef.h                                 windows.devices.power.h
....

This seems to be a recurrent issue, which is due to the specification in the .pc file:

• graphite2.pc doesn't use full filepaths msys2/MINGW-packages#6958
• MSYS paths incorrectly recognized as relative on Windows commercialhaskell/stack#1989
• Does not build on Windows haskell-hvr/brotli#3

To Reproduce
Steps to reproduce the behavior:

$ cat aa.cabal
cabal-version:      3.0
name:               aa
version:            0.1.0.0
-- synopsis:
-- description:
license:            BSD-3-Clause
license-file:       LICENSE
author:             Javier Sagredo
maintainer:         [email protected]
-- copyright:
category:           Codec
build-type:         Simple
extra-doc-files:    CHANGELOG.md
-- extra-source-files:

common warnings
    ghc-options: -Wall

library
    import:           warnings
    exposed-modules:  MyLib
    -- other-modules:
    -- other-extensions:
    build-depends:    base ^>=4.18.1.0
    hs-source-dirs:   src
    default-language: Haskell2010
    pkgconfig-depends: tcl, tre
$ cabal build
Warning: this is a debug build of cabal-install with assertions enabled.
Build profile: -w ghc-9.6.3 -O1
In order, the following will be built (use -v for more details):
 - aa-0.1.0.0 (lib) (first run)
Warning: this is a debug build of cabal-install with assertions enabled.
Preprocessing library for aa-0.1.0.0...
Building library for aa-0.1.0.0...
Warning: this is a debug build of cabal-install with assertions enabled.
Error: [Cabal-7125]
Failed to build aa-0.1.0.0. The failure occurred during the final install step. The exception was:
  Error: [Cabal-8012]
'C:\ghcup\bin\ghc-pkg.exe' exited with an error:
aa-0.1.0.0: Warning: haddock-interfaces: C:\Users\Javier\aa\dist-newstyle\build\x86_64-windows\ghc-9.6.3\aa-0.1.0.0\doc\html\aa\aa.haddock doesn't exist or isn't a file
aa-0.1.0.0: Warning: haddock-html: C:\Users\Javier\aa\dist-newstyle\build\x86_64-windows\ghc-9.6.3\aa-0.1.0.0\doc\html\aa doesn't exist or isn't a directory
aa-0.1.0.0: include-dirs: /mingw64/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)
aa-0.1.0.0: include-dirs: /mingw64/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)

Expected behavior
It should understand either /mingw64/include as C:\msys64\mingw64\include

System information

• Operating system: Windows 11, MINGW64_NT-10.0-22621
• cabal HEAD (but any would do)
• ghc 9.6.3

[Mikolaj]

@mpickering, @bgamari: any comment from the GHC side?

[jasagredo]

It seems this is triggered by code in ghc-pkg/Main.hs calling isRelative on a path.

[hasufell]

I don't understand exactly what you are doing. Are you hardcoding /mingw64/include in cabal.config? That is a user error, not a cabal or ghc bug.

[jasagredo]

Pkgconf packages write it that way, most if not all of them:

❯ cat /mingw64/lib/pkgconfig/termcap.pc
prefix=/mingw64
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include

Name: Termcap
Description: GNU Termcap library and data base that enables programs to use display terminals in a terminal-independent manner
URL: https://www.gnu.org/software/termutils/
Version: 1.3.1
Libs: -L${libdir} -ltermcap
Cflags: -I${includedir}

I'm not hardcoding it in my config (which in any case should still work). 142 out of 144 pkgconf files I have in my machine use this terminology:

❯ cd /mingw64/lib/pkgconfig
❯ ls -1 | wc -l
144
❯ rg "prefix.*mingw64" | grep -v "C" | grep -v "exec"| wc -l
142

And I did not manipulate those. They come from installing stuff via MinGW's pacman

[hasufell]

Are you using pkgconf or mingw-w64-pkgconf?

[jasagredo]

I'm using mingw-w64-x86_64-pkgconf on its latest version.

[hasufell]

msys2/MINGW-packages#6958 suggests this is a bug in the respective packages (in this case termcap?).

[jasagredo]

Wait a second:

$ rg "\-I/mingw"
tre.pc
10:Cflags: -I${includedir} -D_FORTIFY_SOURCE=2 -D__USE_MINGW_ANSI_STDIO=1 -I/mingw64/include

libwmf.pc
10:Cflags: -I/mingw64/include/freetype2 -I/mingw64/include/libpng16 -I/mingw64/include/harfbuzz -I/mingw64/include/glib-2.0 -I/mingw64/lib/glib-2.0/include

isl.pc
18:Cflags: -I${includedir} -I/mingw64/include

ddjvuapi.pc
13:Cflags: -I/mingw64/include
$ PKG_CONFIG_SYSTEM_INCLUDE_PATH=1 pkgconf --cflags-only-I tre
-IC:/msys64/mingw64/include -I/mingw64/include

Did I just by luck (I selected a couple of packages randomly) hit one of the 4 packages that define include directories hardcoded in the Cflags?

[jasagredo]

Ah, if I manually remove that -I/mingw64/include extra Cflag it succeeds. Guess it is a bug in the package itself

[hasufell]

Please report those issues upstream.

[jasagredo]

Reported upstream:

• .pc file doesn't work on mingw laurikari/tre#95
• .pc file doesn't work on MinGW caolanm/libwmf#11
• https://sourceforge.net/p/djvu/bugs/356/
• For isl I think I posted in the google groups but I don't see my message in the list of conversations. I don't really understand how it works, I have not used it before.

[jasagredo]

I discussed on MSYS2's Discord server what should be done in this case. The conclusion for these cases seems to be:

If a MinGW package breaks something because of the .pc file containing POSIX paths, the generation of that file has to be patched at the MinGW-packages¹ level to contain Windows paths instead.

So these issues should maybe not be reported to the upstream library but instead a patch to MinGW-packages should be made

Thoughts @hasufell ?

Footnotes

1. https://github.com/msys2/MINGW-packages ↩

[hasufell]

Sure