Cabal: Windows build failure

[georgefst]

Trying to build the gi-cairo package, using ghc-8.10.1 and cabal-3.2.0.0 from Chocolatey. Previously worked with the 8.6.5 Haskell Platform. Log here.

Initially reported on the haskell-gi repo. The stuff about pkg-config there can probably be ignored - that looks like a red herring.

We've run out of ideas really, as neither Cabal nor GHC seem to be outputting any useful error message.

[jneira]

Hi , i am trying to reproduce the error in my windows 10 using msys2, following the instructions of the package. To get the bindings cabal.project suggests execute cabal new-run genBuildInfo -- $(./PKGS.sh)
It fails for me with

Resolving dependencies...
.....
After searching the rest of the dependency tree exhaustively, these were the
goals I've had most trouble fulfilling: base, unix, build-tools

How do you genereated the bindings (gi-cairo and/or the other ones)? i've not found nothing in docs.
Sorry for comment asking for help instead with solutions 😀

[garetxe]

Hi, and thanks for looking into this!

The genBuildInfocommand is for generating the .cabal files for the bindings, but it is probably more convenient to use the already generated ones in hackage.

For instance, if I put the following into test.hs:

{-# LANGUAGE OverloadedStrings, OverloadedLabels #-}
{- cabal:
build-depends: base, haskell-gi-base, gi-gtk == 3.0.*
-}

import qualified GI.Gtk as Gtk
import Data.GI.Base

main :: IO ()
main = do
  Gtk.init Nothing

  win <- new Gtk.Window [ #title := "Hi there" ]

  on win #destroy Gtk.mainQuit

  button <- new Gtk.Button [ #label := "Click me" ]

  on button #clicked (set button [ #sensitive := False,
                                   #label := "Thanks for clicking me" ])

  #add win button

  #showAll win

  Gtk.main

and run cabal run test.hs I get the same error as @georgefst in a Windows 10 VM.

[jneira]

Well i am still trying to install it looking in the issue tracker and reviewing the install instructions for win.

It is a shot in the dark but with i've got weird error in windows in the past, not always obvious, due to the long path issue. I've observed you have the cabal store-dir in the default location: %APPDATA%\cabal\store.
I would advise, even if it does not fix this concrete issue to change it to the shortest path possible (like C:\sd). For that you can change the value globally in %APPDATA%\cabal\config adding a line with store-dir: C:\sd

[jneira]

After following closely the instructions i got to build gi-cairo (i tried inside a msys console and it failed, although i think it should work):

D:\dev\ws\haskell\gi-cairo-1.0.23>set PATH=D:\dev\app\msys2-20180531\mingw64\bin;D:\dev\app\msys2-20180531\usr\bin;%PATH%

D:\dev\ws\haskell\gi-cairo-1.0.23>set PKG_CONFIG_PATH=D:\dev\app\msys2-20180531\mingw64\lib\pkgconfig

D:\dev\ws\haskell\gi-cairo-1.0.23>set XDG_DATA_DIRS=D:\dev\app\msys2-20180531\mingw64\share

D:\dev\ws\haskell\gi-cairo-1.0.23>cabal build -w ghc-8.10.1
Resolving dependencies...
Build profile: -w ghc-8.10.1 -O1
In order, the following will be built (use -v for more details):
 - gi-cairo-1.0.23 (lib:gi-cairo) (first run)
Configuring gi-cairo-1.0.23...
Preprocessing library for gi-cairo-1.0.23..
Building library for gi-cairo-1.0.23..
[ 1 of 17] Compiling GI.Cairo.Config  ( GI\Cairo\Config.hs, D:\\dev\ws\haskell\gi-cairo-1.0.23\dist-newstyle\build\x86_64-windows\ghc-8.10.1\gi-cairo-1.0.23\build\GI\Cairo\Config.o )
[ 2 of 17] Compiling GI.Cairo.Enums   ( GI\Cairo\Enums.hs, D:\\dev\ws\haskell\gi-cairo-1.0.23\dist-newstyle\build\x86_64-windows\ghc-8.10.1\gi-cairo-1.0.23\build\GI\Cairo\Enums.o )
[ 3 of 17] Compiling GI.Cairo.Functions ( GI\Cairo\Functions.hs, D:\\dev\ws\haskell\gi-cairo-1.0.23\dist-newstyle\build\x86_64-windows\ghc-8.10.1\gi-cairo-1.0.23\build\GI\Cairo\Functions.o )
[ 4 of 17] Compiling GI.Cairo.Structs.Context ( GI\Cairo\Structs\Context.hs, D:\\dev\ws\haskell\gi-cairo-1.0.23\dist-newstyle\build\x86_64-windows\ghc-8.10.1\gi-cairo-1.0.23\build\GI\Cairo\Structs\Context.o )
[ 5 of 17] Compiling GI.Cairo.Structs.Device ( GI\Cairo\Structs\Device.hs, D:\\dev\ws\haskell\gi-cairo-1.0.23\dist-newstyle\build\x86_64-windows\ghc-8.10.1\gi-cairo-1.0.23\build\GI\Cairo\Structs\Device.o )
[ 6 of 17] Compiling GI.Cairo.Structs.FontFace ( GI\Cairo\Structs\FontFace.hs, D:\\dev\ws\haskell\gi-cairo-1.0.23\dist-newstyle\build\x86_64-windows\ghc-8.10.1\gi-cairo-1.0.23\build\GI\Cairo\Structs\FontFace.o )
[ 7 of 17] Compiling GI.Cairo.Structs.FontOptions ( GI\Cairo\Structs\FontOptions.hs, D:\\dev\ws\haskell\gi-cairo-1.0.23\dist-newstyle\build\x86_64-windows\ghc-8.10.1\gi-cairo-1.0.23\build\GI\Cairo\Structs\FontOptions.o )
[ 8 of 17] Compiling GI.Cairo.Structs.Matrix ( GI\Cairo\Structs\Matrix.hs, D:\\dev\ws\haskell\gi-cairo-1.0.23\dist-newstyle\build\x86_64-windows\ghc-8.10.1\gi-cairo-1.0.23\build\GI\Cairo\Structs\Matrix.o )
[ 9 of 17] Compiling GI.Cairo.Structs.Path ( GI\Cairo\Structs\Path.hs, D:\\dev\ws\haskell\gi-cairo-1.0.23\dist-newstyle\build\x86_64-windows\ghc-8.10.1\gi-cairo-1.0.23\build\GI\Cairo\Structs\Path.o )
[10 of 17] Compiling GI.Cairo.Structs.Pattern ( GI\Cairo\Structs\Pattern.hs, D:\\dev\ws\haskell\gi-cairo-1.0.23\dist-newstyle\build\x86_64-windows\ghc-8.10.1\gi-cairo-1.0.23\build\GI\Cairo\Structs\Pattern.o )
[11 of 17] Compiling GI.Cairo.Structs.Rectangle ( GI\Cairo\Structs\Rectangle.hs, D:\\dev\ws\haskell\gi-cairo-1.0.23\dist-newstyle\build\x86_64-windows\ghc-8.10.1\gi-cairo-1.0.23\build\GI\Cairo\Structs\Rectangle.o )
[12 of 17] Compiling GI.Cairo.Structs.RectangleInt ( GI\Cairo\Structs\RectangleInt.hs, D:\\dev\ws\haskell\gi-cairo-1.0.23\dist-newstyle\build\x86_64-windows\ghc-8.10.1\gi-cairo-1.0.23\build\GI\Cairo\Structs\RectangleInt.o )
[13 of 17] Compiling GI.Cairo.Structs.Region ( GI\Cairo\Structs\Region.hs, D:\\dev\ws\haskell\gi-cairo-1.0.23\dist-newstyle\build\x86_64-windows\ghc-8.10.1\gi-cairo-1.0.23\build\GI\Cairo\Structs\Region.o )
[14 of 17] Compiling GI.Cairo.Structs.ScaledFont ( GI\Cairo\Structs\ScaledFont.hs, D:\\dev\ws\haskell\gi-cairo-1.0.23\dist-newstyle\build\x86_64-windows\ghc-8.10.1\gi-cairo-1.0.23\build\GI\Cairo\Structs\ScaledFont.o )
[15 of 17] Compiling GI.Cairo.Structs.Surface ( GI\Cairo\Structs\Surface.hs, D:\\dev\ws\haskell\gi-cairo-1.0.23\dist-newstyle\build\x86_64-windows\ghc-8.10.1\gi-cairo-1.0.23\build\GI\Cairo\Structs\Surface.o )
[16 of 17] Compiling GI.Cairo.Structs ( GI\Cairo\Structs.hs, D:\\dev\ws\haskell\gi-cairo-1.0.23\dist-newstyle\build\x86_64-windows\ghc-8.10.1\gi-cairo-1.0.23\build\GI\Cairo\Structs.o )
[17 of 17] Compiling GI.Cairo         ( GI\Cairo.hs, D:\\dev\ws\haskell\gi-cairo-1.0.23\dist-newstyle\build\x86_64-windows\ghc-8.10.1\gi-cairo-1.0.23\build\GI\Cairo.o )

It worked with ghc-8.8.3 too. So maybe the path of store-dircould be related.

[jneira]

I've ran the test script posted above too:

D:\dev\ws\haskell\gi-cairo-1.0.23>cabal run Test.hs
Resolving dependencies...
Build profile: -w ghc-8.8.3 -O1
In order, the following will be built (use -v for more details):
 - gi-glib-2.0.23 (lib:gi-glib) (requires download & build)
 - gi-gobject-2.0.22 (lib:gi-gobject) (requires download & build)
 - gi-pango-1.0.22 (lib:gi-pango) (requires download & build)
 - gi-gio-2.0.26 (lib:gi-gio) (requires download & build)
 - gi-atk-2.0.21 (lib:gi-atk) (requires download & build)
 - gi-gdkpixbuf-2.0.23 (lib:gi-gdkpixbuf) (requires download & build)
 - gi-gdk-3.0.22 (lib:gi-gdk) (requires download & build)
 - gi-gtk-3.0.33 (lib:gi-gtk) (requires download & build)
 - fake-package-0 (exe:script) (first run)
Downloading  gi-glib-2.0.23
...........
 [498 of 500] Compiling GI.Gtk.Structs.WindowGeometryInfo ( GI\Gtk\Structs\WindowGeometryInfo.hs, D:\dev\ws\haskell\gi-cairo-1.0.23\dist-newstyle\build\x86_64-windows\ghc-8.8.3\gi-gtk-3.0.33\build\GI\Gtk\Structs\WindowGeometryInfo.o )
[499 of 500] Compiling GI.Gtk.Structs   ( GI\Gtk\Structs.hs, D:\dev\ws\haskell\gi-cairo-1.0.23\dist-newstyle\build\x86_64-windows\ghc-8.8.3\gi-gtk-3.0.33\build\GI\Gtk\Structs.o )
[500 of 500] Compiling GI.Gtk           ( GI\Gtk.hs, D:\dev\ws\haskell\gi-cairo-1.0.23\dist-newstyle\build\x86_64-windows\ghc-8.8.3\gi-gtk-3.0.33\build\GI\Gtk.o )
Configuring executable 'script' for fake-package-0..
Preprocessing executable 'script' for fake-package-0..
Building executable 'script' for fake-package-0..
[1 of 1] Compiling Main             ( Main.hs, D:\dev\ws\haskell\gi-cairo-1.0.23\dist-newstyle\build\x86_64-windows\ghc-8.8.3\fake-package-0\x\script\build\script\script-tmp\Main.o )
Linking D:\dev\ws\haskell\gi-cairo-1.0.23\dist-newstyle\build\x86_64-windows\ghc-8.8.3\fake-package-0\x\script\build\script\script.exe ...

and a little window born! 😄

[garetxe]

Thanks for looking into this @jneira! Changing store-dir did not fix the issue for me, but looking more closely into what you did, doing the following did fix the issue for me!

C:\Users\User>set PATH=C:\tools\msys64\mingw64\bin;C:\tools\msys64\usr\bin;%PATH%
C:\Users\User>set PKG_CONFIG_PATH=C:\tools\msys64\mingw64\lib\pkgconfig
C:\Users\User>set XDG_DATA_DIRS=C:\tools\msys64\mingw64\share
C:\Users\User>cabal run test.hs

So it seems like one needs to set up the environment variables properly (although I am still unclear on what exactly is breaking if you don't).

@georgefst Does this work for you too?

[georgefst]

@garetxe I was minutes away from posting the same discovery (unfortunately my Windows machine is incredibly slow and I'm still waiting for the build to fully complete, but it seems to be over the hurdles). Thanks @jneira !

I feel a bit silly for not setting the environment variables, but I think with the old Haskell Platform method it was clearer that they were needed. @Mistuke Is there any way that the chocolatey installer could set these, or at least prompt the user to do so? Seeing as they aren't specific to haskell-gi, one would expect other packages could hit the same issue.

Anyway, I guess this isn't really a Cabal issue (aside from the lack of a useful error message). I did hit two seemingly unrelated ones while looking into this, but I'll report those separately...

[georgefst]

For reference, with PowerShell, the necessary commands were:

$Env:PATH += ";C:\tools\msys64\usr\bin"
$Env:PATH += ";C:\tools\msys64\mingw64\bin"
$Env:XDG_DATA_DIRS = "C:\tools\msys64\mingw64\share"
$Env:PKG_CONFIG_PATH = "C:\tools\msys64\mingw64\lib\pkgconfig"

[jneira]

@georgefst @garetxe you are welcome! i took the env vars values from the official docs about installing it in windows: https://github.com/haskell-gi/haskell-gi/wiki/Using-haskell-gi-in-Windows
The strange think is you have to use a cmd or ps console and set the path to mingw but using directly the mingw console which has those paths by default, it did not work at first!
Maybe i did something wrong or the build in the cmd configured something cause now it works too in the mingw console.

[georgefst]

Yes, the irony is that this all started with me suggesting updating those docs (issue). And then I forgot about the one part of them that remains useful.

I've never been entirely sure about how all these things interact (I'm not really a Windows user), but my impression is that the majority of users of Haskell on Windows aren't supposed to know or care about MSYS/MinGW (e.g. with the chocolatey installer, there aren't even start menu shortcuts created for them), so I figured PowerShell instructions would make the most sense.

[Mistuke]

For reference, with PowerShell, the necessary commands were:

> $Env:PATH += ";C:\tools\msys64\usr\bin"
> $Env:PATH += ";C:\tools\msys64\mingw64\bin"

The problem is these are very dangerous things to do. You're exposing binaries and shared libraries with the same name but completely different ABIs. If you want to run msys2 tools you should use the mingw shell which isolates the paths or you should use cabal run.

This isn't done to prevent cryptic errors when people copy dlls to these folders so they're "on their path". So there isn't one good solution here.

```

$Env:XDG_DATA_DIRS = "C:\tools\msys64\mingw64\share"
$Env:PKG_CONFIG_PATH = "C:\tools\msys64\mingw64\lib\pkgconfig"
```

This is unrelated to chocolatey's GHC installs.

[Mistuke]

I feel a bit silly for not setting the environment variables, but I think with the old Haskell Platform method it was clearer that they were needed.

The old platform also wouldn't have set XDG_DATA_DIRS or PKG_CONFIG_PATH as far as I'm aware. Those are unrelated to Haskell.

As for PATH. Changing a user's System Path to contain binaries compiled with a cygwin runtime and a old vc runtime and GHC's own one is rather funky. Chocolatey already adds these just not globally. I.e. cabal is able to find it so cabal run works. This is to cut down on the number of bug reports I got on GHC for bad configurations.

I can however add an option for if people want to globally modify their PATH. It's up to them to solve any issues though.

[georgefst]

Right, some good points there. We're basing this on some fairly old instructions, so it's possible that not all 4 of those changes were actually needed. I'll investigate that first.

In particular, I'd hope that the additions to PATH might be unnecessary since those do indeed seem to have been correctly automatically configured in the Cabal config file.

As for XDG_DATA_DIRS and PKG_CONFIG_PATH, we can keep those in the haskell-gi instructions, but I'm curious about the likelihood of other packages having the same issues. @garetxe do you know exactly what gi-cairo (and some, but not all, of the other gi- packages) do that relies on these being set correctly?

[garetxe]

@garetxe do you know exactly what gi-cairo (and some, but not all, of the other gi- packages) do that relies on these being set correctly?

PKG_CONFIG_PATH is for telling pkg-config where to look for the .pc files (the pkg-config files with the information about which versions of packages are installed, and where). XDG_DATA_DIRS is needed for telling haskell-gi where to find the .gir files. These are the files that contain the introspection data that we use for generating the bindings.

[garetxe]

Just to avoid confusion: XDG_DATA_DIRS is not specific to haskell-gi. It is for programs following the XDG base directory spec, which is a way for many modern programs to query the system to know where some standard dirs are. XDG_DATA_DIRS generally includes /usr/share, and any other user-supplied search paths for general data files.

[Mistuke]

To be clear, I'm not opposed to adding these at all to the package. The only one i really don't want is the PATH one.

[garetxe]

I just gave it a test, and the minimal set I need is

$Env:PATH += ";C:\tools\msys64\mingw64\bin"
$Env:XDG_DATA_DIRS = "C:\tools\msys64\mingw64\share"
$Env:PKG_CONFIG_PATH = "C:\tools\msys64\mingw64\lib\pkgconfig"

So it seems like we do need to set the path properly, at least partly. I am still not sure why.

[Mistuke]

What's the error when you don't set PATH?

[garetxe]

I just put the a gist here.

[Mistuke]

What's in the build log?

Redirecting build log to {handle:
C:\Users\User\AppData\Roaming\cabal\logs\ghc-8.10.1\gi-cairo-1.0.23-206a4eef239756fe5390aea9db0c8b08cd1f49d4.log}

[garetxe]

Thanks for taking a look. Here is what that says:

[1 of 1] Compiling Main             ( C:\Users\User\AppData\Local\Temp\cabal-repl.-5848\dist-newstyle\tmp\src-5848\gi-cairo-1.0.23\dist\setup\setup.hs, C:\Users\User\AppData\Local\Temp\cabal-repl.-5848\dist-newstyle\tmp\src-5848\gi-cairo-1.0.23\dist\setup\Main.o )
Linking C:\Users\User\AppData\Local\Temp\cabal-repl.-5848\dist-newstyle\tmp\src-5848\gi-cairo-1.0.23\dist\setup\setup.exe ...

[garetxe]

One thing I notice playing with this is that pkg-config is still failing, according to the cabal log. If I copy pkg.config.exe to the build directory, and I try to run from the file explorer, I get a message from a missing libwinpthread-1.dll:

The code execution cannot proceed because libwinpthread-1.dll was not found. reinstalling the program may fix this problem

But when I try to run it from powershell it fails silently:

PS C:\Users\User> .\pkg-config.exe --version
PS C:\Users\User>

Is there any way of making powershell complain loudly about such missing libraries?

[garetxe]

I tried doing the same thing in cmd.exe, and this one complains loudly about linking errors, so I could fix the silent errors by copying the following set of libraries from C:\tools\msys64\mingw64\bin to the build directory:

libffi-7.dll               libgmodule-2.0-0.dll  libpcre-1.dll
libgio-2.0-0.dll           libgobject-2.0-0.dll  libwinpthread-1.dll
libgirepository-1.0-1.dll  libiconv-2.dll        zlib1.dll
libglib-2.0-0.dll          libintl-8.dll

[garetxe]

I guess the question then is how to tell cabal to put these in the search path when linking the setup script. I tried adding a pkgconfig-depends to custom-setup but this just gave a warning Unknown field: pkgconfig-depends.

[Mistuke]

One thing I notice playing with this is that pkg-config is still failing, according to the cabal log. If I copy pkg.config.exe to the build directory, and I try to run from the file explorer, I get a message from a missing libwinpthread-1.dll

You shouldn't do that, that hides the actual error. the question is why does running pkg-config in C:\tools\msys64\mingw64\bin fail. So what happens when you run the pkg-config in that directory in a shell which doesn't have PATH with this.

I guess the question then is how to tell cabal to put these in the search path when linking the setup script. I tried adding a pkgconfig-depends to custom-setup but this just gave a warning Unknown field: pkgconfig-depends.

You shouldn't need to. The standard Windows path search includes the directory where the binary is. That's why the dlls where placed in bin and why bin shouldn't be set globally in PATH.

So let's take a step back, why does C:\tools\msys64\mingw64\bin\pkg-config.exe fail. That's the issue.. it seems to work for me..

[garetxe]

So what happens when you run the pkg-config in that directory in a shell which doesn't have PATH with this.

If I run C:\tools\msys64\mingw64\bin\pkg-config from any directory it works. Not sure where the error in the cabal log is coming from.

So let's take a step back, why does C:\tools\msys64\mingw64binpkg-config.exe fail. That's the issue.. it seems to work for me..

What do you have in your PATH?

[garetxe]

For reference, here is what I see in powershell in a clean Windows 10 Virtual Machine:

PS C:\Users\User> echo $env:PATH
C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Windows\System32\OpenSSH\;C:\Program Files\dotnet\;C:\Program Files\Microsoft SQL Server\130\Tools\Binn\;C:\Program Files\Microsoft SQL Server\Client SDK\ODBC\170\Tools\Binn\;C:\ProgramData\chocolatey\bin;C:\Program Files\Git\cmd;C:\Users\User\AppData\Local\Microsoft\WindowsApps;;C:\Users\User\AppData\Local\Programs\Microsoft VS Code\bin;C:\Users\User\AppData\Roaming\cabal\bin;C:\ProgramData\chocolatey\lib\ghc\tools\ghc-8.10.1\bin;C:\tools\msys64;
PS C:\Users\User>

[Mistuke]

So let's take a step back, why does C:\tools\msys64\mingw64binpkg-config.exe fail. That's the issue.. it seems to work for me..

What do you have in your PATH?

Nothing Haskell related aside from GHC. I don't change paths for global tools. I'll in sandbox mode.

[garetxe]

OK, thanks a lot. Let me summarize what I know so far:

The build failure is easy (if time-consuming) to reproduce. First, run these as admin in a fresh Windows 10 VM to set everything up:

1. Install the Haskell platform via chocolatey
2. mingw64-pkg install pkg-config
3. mingw64-pkg install gobject-introspection
4. mingw64-pkg install gtk3
5. cabal user-config init -f
6. choco install cabal --reinstall --force
7. cabal update

Then, as an ordinary user, in cmd.exe:

1. set PKG_CONFIG_PATH=C:\tools\msys64\mingw64\lib\pkgconfig
2. set XDG_DATA_DIRS=C:\tools\msys64\mingw64\share
3. cabal install gi-cairo

This will fail, with a bunch of dialogs of the form The code execution cannot proceed because xxx.dll was not found. reinstalling the program may fix this problem, with the list of xxx.dll appearing in the comment above. The problem appears to happen when the custom setup script that gi-cairo uses is executed.

The missing libraries seem to be, for the most part, those required by haskell-gi, which is listed as an explicit dependency of custom-setup.

Here is one guess about what is happening: the custom setup in gi-cairo is linked to various dlls (indirectly via its dependence on haskell-gi, which depends explicitly on these dlls). cabal does set up the path for searching for these dlls correctly when linking the setup script, but not when executing it.

[garetxe]

As a check of the guess above, I copied the problematic dlls to C:\Users\User\gi-cairo-1.0.23\dist-newstyle\build\x86_64-windows\ghc-8.10.1\gi-cairo-1.0.23\setup before building (here I am trying to build a copy of gi-cairo-1.0.23 that I downloaded), and the errors are gone.

(I am of course not suggesting that this is the right fix, I am just trying to see if what I am guessing above holds water.)

[garetxe]

OK, I think that the previous comments were on the right track. I made a much simpler test case, you can find it at https://github.com/garetxe/cabal-custom-setup.

[Mistuke]

Ugh... custom setups are a can of worms.. @phadej any idea what's going on here?

[phadej]

I don't know.

cabal does set up the path for searching for these dlls correctly when linking the setup script, but not when executing it.

That sounds very weird. cabal does build e.g. test executables and run them fine, but I haven't exercised pkg-config on windows myself. Maybe I always had required DLLs (e.g. for PostgreSQL) somehow globally available.

Sorry, but I cannot help here.

[Mistuke]

OK, thanks a lot. Let me summarize what I know so far:

The build failure is easy (if time-consuming) to reproduce. First, run these as admin in a fresh Windows 10 VM to set everything up:

1. Install the Haskell platform via chocolatey
2. mingw64-pkg install pkg-config
3. mingw64-pkg install gobject-introspection
4. mingw64-pkg install gtk3
5. cabal user-config init -f
6. choco install cabal --reinstall --force

I can install pkg-config automatically from the package, I don't think that's an issue, it's small and I think given the bit of a circular dependency maybe that's the best thing.

This means you don't need 2, 5 and 6.

1. cabal update

Then, as an ordinary user, in cmd.exe:

1. set PKG_CONFIG_PATH=C:\tools\msys64\mingw64\lib\pkgconfig
2. set XDG_DATA_DIRS=C:\tools\msys64\mingw64\share

I can then set these automatically as well if I install pkg-config. These are safe as they shouldn't interact with anything else.

Any objections? If not I'll see if I can't have them in this weekend's nightliest to test.

[Mistuke]

OK, I think that the previous comments were on the right track. I made a much simpler test case, you can find it at https://github.com/garetxe/cabal-custom-setup.

ok, I will take a look, but It will likely be end of next week.. I have some high priority tasks on GHC to round up first..

[garetxe]

Any objections? If not I'll see if I can't have them in this weekend's nightliest to test.

This would be great, thanks!

ok, I will take a look, but It will likely be end of next week.. I have some high priority tasks on GHC to round up first..

Sure, thanks a lot! Just to note: the minimal testcase in https://github.com/garetxe/cabal-custom-setup does not involve haskell-gi or the gi-* bindings in any way, probably any custom setup using a pkg-config dependency will fail in the same way. (For a minute I thought that the funky things that we do in the gi-* custom setup script were to blame, but the testcase above shows that that is not the case.)

[DrewFenwick]

I've found that setting the environment variables only seems to work for me in cmd and not in powershell or the System Properties gui, otherwise the same exit code -1073741515 issue as above occurs.

I had previously got a project building, running and working after reading through this thread and using cmd. (After this, cabal build also worked in powershell since gi-gtk was already built.)
Then when I tried to do cabal repl in powershell I got a GHC panic relating to linking a libgirepository-1.0-1 dll.

I then created a new project, intending to reproduce the issue with the minimal amount of dependencies, but when I tried to build I ran into the same exit code -1073741515 issue again. This time I was on powershell, but it hadn't occured to me that this would be an issue.

I went back to the original project (on powershell) and after running cabal update and cabal clean, haskell-gi libraries had to be rebuilt, but this failed with the same exit code -1073741515 problem.

PS C:\Users\Drew Fenwick\Documents\Github\game-time> cabal build
Build profile: -w ghc-8.10.1 -O1
In order, the following will be built (use -v for more details):
 - gi-cairo-1.0.23 (lib:gi-cairo) (requires build)
 - gi-glib-2.0.23 (lib:gi-glib) (requires build)
 - gi-gobject-2.0.22 (lib:gi-gobject) (requires build)
 - gi-pango-1.0.22 (lib:gi-pango) (requires build)
 - gi-gio-2.0.26 (lib:gi-gio) (requires build)
 - gi-atk-2.0.21 (lib:gi-atk) (requires build)
 - gi-gdkpixbuf-2.0.23 (lib:gi-gdkpixbuf) (requires build)
 - gi-gdk-3.0.22 (lib:gi-gdk) (requires build)
 - gi-gtk-3.0.33 (lib:gi-gtk) (requires build)
 - gi-gtk-declarative-0.6.3 (lib) (requires build)
 - gi-gtk-declarative-app-simple-0.6.3 (lib) (requires build)
 - game-time-0.1.0.0 (lib) (configuration changed)
 - game-time-0.1.0.0 (exe:game-time) (first run)
Starting     gi-cairo-1.0.23 (all, legacy fallback)
Starting     gi-glib-2.0.23 (all, legacy fallback)
cabal.exe: Failed to build gi-cairo-1.0.23 (which is required by exe:game-time
from game-time-0.1.0.0). The failure occurred during the configure step. The
build process terminated with exit code -1073741515
Failed to build gi-glib-2.0.23 (which is required by exe:game-time from
game-time-0.1.0.0). The failure occurred during the configure step. The build
process terminated with exit code -1073741515

I could not see anything wrong with my environment variables.

PS C:\Users\Drew Fenwick\Documents\Github\game-time> echo $Env:PKG_CONFIG_PATH
C:\tools\msys64\mingw64\lib\pkgconfig
PS C:\Users\Drew Fenwick\Documents\Github\game-time> echo $Env:XDG_DATA_DIRS
C:\tools\msys64\mingw64\share
PS C:\Users\Drew Fenwick\Documents\Github\game-time> echo $Env:PATH
C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\;C:\Program Files (x86)\Calibre2\;C:\Program Files\Calibre2\;C:\Program Files\Git\cmd;C:\Program Files\PuTTY\;C:\WINDOWS\System32\OpenSSH\;C:\tools\msys64;C:\tools\msys64\bin;C:\tools\msys64\usr\bin;C:\Program Files\PostgreSQL\10\bin;C:\Program Files\emacs\bin\;C:\Program Files\Intel\WiFi\bin\;C:\Program Files\Common Files\Intel\WirelessCommon\;C:\Program Files (x86)\Intel\Intel(R) Management Engine Components\DAL;C:\Program Files\Intel\Intel(R) Management Engine Components\DAL;C:\ProgramData\chocolatey\bin;C:\Program Files\PostgreSQL\12\bin;C:\Users\Drew Fenwick\AppData\Local\git-cola\bin;C:\Users\Drew Fenwick\AppData\Local\Programs\Python\Python38-32\Scripts\;C:\Users\Drew Fenwick\AppData\Local\Programs\Python\Python38-32\;C:\Users\Drew Fenwick\.elan\bin;C:\Users\Drew Fenwick\AppData\Roaming\local\bin;C:\Users\Drew Fenwick\AppData\Local\Microsoft\WindowsApps;C:\Users\Drew Fenwick\AppData\Local\GitHubDesktop\bin;C:\tools\msys64;C:\Program Files\Intel\WiFi\bin\;C:\Users\Drew Fenwick\AppData\Local\Programs\Microsoft VS Code\bin;C:\Users\Drew Fenwick\AppData\Roaming\cabal\bin;C:\ProgramData\chocolatey\lib\ghc\tools\ghc-8.10.1\bin;C:\ProgramData\chocolatey\lib\ghc\tools\ghc-8.8.3\bin;C:\ProgramData\chocolatey\lib\ghc\tools\ghc-8.6.5\bin;C:\Users\Drew Fenwick\AppData\Local\Microsoft\WindowsApps;

Remembering that things originally started working on cmd, I retried building there and. A dialogue box popped up saying:

The code execution cannot proceed because libgirepository-1.0-1.dll was not found. Reinstalling the program may fix this problem.

This is exactly the dll relating to the GHC panic, but I can see that this dll is right there in C:\tools\msys64\mingw64\bin

Remembering that things only started working the first time after setting the environment variables in cmd, I tried that, then cabal build gi-gtk worked (in the same cmd session) and cabal repl worked without causing a GHC panic

I had set previously set the environment variables via the _System Properties>Advanced>Environment Variables_, as well as setting them with the powershell commands suggested above (unsure as to whether both admin and non-admin powershell were tried), and as I showed, they were correct when echoed back to me in powershell. It is unclear to me why building failed.

Is this expected behavior?